{"id":446,"date":"2015-05-27T08:43:01","date_gmt":"2015-05-27T06:43:01","guid":{"rendered":"http:\/\/invidit.de\/blog\/?p=446"},"modified":"2015-07-04T14:37:07","modified_gmt":"2015-07-04T12:37:07","slug":"kein-unit-test-wie-jeder-andere","status":"publish","type":"post","link":"https:\/\/invidit.de\/blog\/kein-unit-test-wie-jeder-andere\/","title":{"rendered":"Kein Unit-Test wie jeder andere"},"content":{"rendered":"

Hallo Spa\u00df-Coder.<\/p>\n

In den ersten beiden Artikeln der Serie zum Thema Testautomatisierung haben wir uns damit besch\u00e4ftigt, warum\u00a0Testautomatisierung sinnvoll ist, und was Unit-Tests sind. Dieser Artikel besch\u00e4ftigt sich heute mit\u00a0unterschiedlichen Arten von Unit-Tests und soll euch ein paar Anregungen geben,\u00a0wozu ihr\u00a0Unit-Tests noch einsetzen k\u00f6nnt.<\/p>\n

 <\/p>\n

Welche Arten von Unit-Tests gibt es?<\/h1>\n

Es gibt eigentlich keine klassische Unterteilung und es sind auch keine „harten“ Unterscheidungsfaktoren, die wir hier auflisten m\u00f6chten. Vielmehr geht es darum aufzuzeigen, wozu Unit-Tests verwendet werden k\u00f6nnen. Auf den generellen Zweck und Nutzen von Unit-Tests sind wir bereits ausf\u00fchrlich eingegangen<\/a>.<\/p>\n

 <\/p>\n

Lern-Test<\/strong><\/h3>\n

Mit Hilfe von Lern-Tests k\u00f6nnen wir sehr einfach und effizient eine neue Technologie erlernen. Das kann eine neue Programmiersprache, ein neues Sprachfeature\u00a0oder eine neue Bibliothek sein, die wir einsetzen m\u00f6chten. Bei Lerntests geht es vor allem darum, Dinge auszuprobieren. Wir \u00fcberlegen uns Anforderungen – z. B. in Form von User-Stories – und formulieren diese in Testf\u00e4lle. Dann versuchen wir dies mit der neuen Technologie oder\u00a0der neuen Bibliothek umzusetzen.<\/p>\n

Beispiel:<\/span><\/p>\n

Mit Java 8 gibt es das tolle neue Feature der Streams. Wie aber funktionieren diese? Was k\u00f6nnen wir alles damit anstellen. Nach dem Studium der generellen Funktion k\u00f6nnen wir uns nun \u00fcberlegen, was wir mit Streams anfangen wollen. Diese Ideen setzen wir nun in Testf\u00e4lle um und implementieren somit unsere ersten Streams.<\/p>\n

Wichtig ist bei Lern-Tests, dass wir diese nicht hinschludern und\u00a0hinterher nicht einfach wegwerfen, sondern behalten. Damit \u00e4ndern sie ihre Form zu Boundary-Tests\u00a0oder Dokumentationstests.<\/p>\n

 <\/p>\n

Boundary-Test<\/strong><\/h3>\n

Unter einem Boundary-Test\u00a0verstehen wir einen Test, der eine Grenze \u00fcberpr\u00fcft. Typischerweise ist dies eine externe Bibliothek. Es kann aber auch eine Komponente eines Kollegen oder eines anderen (Teil-)Teams sein. Mit Hilfe von Boundary-Tests stellen\u00a0wir fest, ob seine neue Version einer Bibliothek kompatibel zu unserem bisherigen Code ist.<\/p>\n

Beispiel:<\/span><\/p>\n

Unsere Anwendung verwendet eine Bibliothek f\u00fcr eine Rechtschreibpr\u00fcfung von Text.\u00a0Nun implementieren wir in Form von Unit-Tests genau diejenigen Funktionen der Bibliothek, die wir auch in unserem Projekt benutzen. Steht nun eine neue Version dieser Bibliothek bereit, k\u00f6nnen wir diese einbinden und unsere Tests aufrufen.\u00a0So k\u00f6nnen wir schnell pr\u00fcfen, ob die neue Version mit unserer Anwendung zusammen funktioniert oder nicht. Falls nicht sehen wir unmittelbar, wo es Probleme gibt und k\u00f6nnen diese recht schnell beheben (oder schnell einsch\u00e4tzen, ob sich der Aufwand lohnt).<\/p>\n

Boundary-Tests sind sicherlich nicht immer sinnvoll, k\u00f6nnen aber mitunter n\u00fctzliche Dienste leisten, vor allem bei wichtigen, zentralen Bibliotheken unserer Anwendung. Auch bei sicherheitsrelevanten Bibliotheken\u00a0ist es \u00fcberlegenswert einen Boundary-Test zu schreiben, da diese oft sehr h\u00e4ufig aktualisiert werden. Wenn es eine neue Version gibt, sollte es f\u00fcr uns keinen Grund geben, diese nicht einzusetzen. Diese Unsicherheit schlie\u00dfen wir durch Boundary-Tests aus.<\/p>\n

 <\/p>\n

Dokumentationstest<\/strong><\/h3>\n

Bei Dokumentationstests geht es darum,\u00a0die Verwendung einer\u00a0Komponente zu dokumentieren.\u00a0Mit Hilfe dieser Tests kann ein Entwickler sehr schnell erkennen, wie eine Komponente verwendet werden kann und soll.<\/p>\n

 <\/p>\n

Beispiel:<\/span><\/p>\n

Wir haben eine neue Komponente erstellt. Statt nun eine umfangreiche Dokumentation zu verfassen, wie diese funktioniert, k\u00f6nnen wir auch f\u00fcr alle\u00a0Anwendungsf\u00e4lle Unit-Tests schreiben, die das Verhalten erkl\u00e4ren. Tests, die das gew\u00fcnschte Verhalten sicherstellen, haben wir ja sowieso schon erstellt. Vielleicht reicht es, wenn wir diesen noch ein paar erkl\u00e4rende Kommentare hinzuf\u00fcgen und schon wei\u00df ein anderer Programmierer, wie unsere Komponente zu verwenden ist. Auch als Kopiervorlage k\u00f6nnen diese Tests dienen.<\/p>\n

Beispiel 2:<\/span><\/p>\n

Nehmen wir nochmal das in den Lerntests verwendete Beispiel. Wir haben nun Testf\u00e4lle f\u00fcr die Verwendung von Streams in Java. Wenn wir diese Tests nun sauber strukturiert, sprechend benannt und ordentlich abgelegt haben, k\u00f6nnen wir diese nun immer mal wieder als Referenz heranziehen. Stellt sich uns die Frage „Wie war das nochmal?“, finden wir hier sicherlich die Antwort. Und wenn nicht, m\u00fcssen wir es ohnehin herausfinden und k\u00f6nnen einen passenden Test erg\u00e4nzen.<\/p>\n

Der Aufwand, Dokumentationstests zu erstellen ist gering (vorausgesetzt, es bestehen bereits ausreichend Unit-Tests), hilft aber vor allem, bei der Arbeit im Team. Es kann aber auch dann hilfreich sein, wenn man selbst eine Bibliothek erstellt und Monate sp\u00e4ter nochmal in einem anderen Projekt verwenden m\u00f6chte. Auch hier wird die Frage nach dem „Wie war das nochmal?“ schnell beantwortet.<\/p>\n

 <\/p>\n

 <\/p>\n

Unsere Erfahrung mit\u00a0den unterschiedlichen Arten<\/h1>\n

Bislang haben auch wir in erster Linie klassische Unit-Tests <\/a>geschrieben, welche die Funktionsf\u00e4higkeit unserer Komponenten sicherstellen. Hin und wieder setzen wir Lern-Tests ein, um uns mit was neuem zu besch\u00e4ftigen. Diese haben wir aber meist mit wenig Sorgfalt behandelt, sodass wir sie irgendwann einfach gel\u00f6scht haben.<\/p>\n

Oft h\u00e4tten\u00a0uns vor allem Dokumentationstests und Boundary-Tests geholfen. Wir haben manches Mal eine Bibliothek ausgetauscht\u00a0um dann m\u00fchsam herauszufinden, wo das Problem liegt. Auch zu unseren eigenen Bibliotheken stellen wir uns manchmal die Frage „Wie war das nochmal?“. Wir schauen dann in alten Projekten oder den Quellcode der Bibliothek nach. Schneller w\u00e4re hier sicherlich der Blick in die Tests.<\/p>\n

 <\/p>\n

Zusammenfassung<\/h1>\n

Es gibt die verschiedensten Gr\u00fcnde, warum man einen Unit-Test erstellen sollte. Er unterst\u00fctzt\u00a0neben der Absicherung eines Systems vor ungewollten \u00c4nderungen\u00a0in erster Linie dabei, das System von vorneherein sauber zu designen. Dabei wird die Sicht des „Benutzers“ der Schnittstelle unserer Komponente eingenommen. Dar\u00fcber hinaus helfen Unit-Tests dabei, eine neue Technik oder Bibliothek kennenzulernen oder unser System\u00a0vor \u00c4nderungen von Au\u00dfen (an den Abh\u00e4ngigkeiten) zu sch\u00fctzen. Zu guter Letzt bildet es eine elegante Form, unsere Komponente in Form von Beispielen zu\u00a0dokumentieren. Wir hoffen, euch einige Anregungen gegeben zu haben, um noch mehr aus euren Unit-Tests herauszuholen.<\/p>\n

 <\/p>\n

Viel Spa\u00df beim Anwenden.<\/p>\n

Eure Spa\u00df-Coder<\/p>\n

 <\/p>\n

 <\/p>\n

Dieser Artikel basiert neben unseren Erfahrungen auf folgenden Quellen:<\/p>\n

    \n
  • http:\/\/www.it-agile.de\/wissen\/praktiken\/agiles-testen\/unit-tests\/<\/li>\n
  • Martin, Robert C. Clean Code-Refactoring, Patterns, Testen und Techniken f\u00fcr sauberen Code: Deutsche Ausgabe<\/i>. MITP-Verlags GmbH & Co. KG, 2013.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"

    Hallo Spa\u00df-Coder. In den ersten beiden Artikeln der Serie zum Thema Testautomatisierung haben wir uns damit besch\u00e4ftigt, warum\u00a0Testautomatisierung sinnvoll ist, und was Unit-Tests sind. Dieser Artikel besch\u00e4ftigt sich heute mit\u00a0unterschiedlichen Arten von Unit-Tests und soll euch ein paar Anregungen geben,\u00a0wozu ihr\u00a0Unit-Tests noch einsetzen k\u00f6nnt.   Welche Arten von Unit-Tests gibt es? Es gibt eigentlich keine […]<\/p>\n","protected":false},"author":1,"featured_media":451,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[90],"tags":[83,82,69,77,75,81],"_links":{"self":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/446"}],"collection":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/comments?post=446"}],"version-history":[{"count":4,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/446\/revisions"}],"predecessor-version":[{"id":450,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/446\/revisions\/450"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/media\/451"}],"wp:attachment":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/media?parent=446"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/categories?post=446"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/tags?post=446"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}