Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: MITP
- Kategorie: Wissenschaft und neue Technologien
- Serie: mitp Professional
- Sprache: Deutsch
Lesbare, wartbare und zuverlässige Tests entwickeln Fakes, Stubs, Mock-Objekte und Isolation-(Mocking-)Frameworks Einfache Dependency-Injection-Techniken und das Refactoring von Legacy Code Sie wissen, dass Sie Unit Tests durchführen sollten – warum machen Sie es noch nicht? Wenn Sie Anfänger auf dem Gebiet der Unit Tests sind, wenn Sie Unit Tests mühsam finden oder wenn Sie, gemessen am Aufwand, einfach kein ausreichendes Ergebnis erzielen, dann sollten Sie dieses Buch lesen. Roy Osherove führt Sie Schritt für Schritt vom Schreiben Ihres ersten, einfachen Unit Tests bis hin zum Erstellen kompletter Test-Sets, die wartbar, lesbar und zuverlässig sind. Sie werden schnell zu fortgeschrittenen Themen wie Mocks und Stubs hingeführt, während Sie die Verwendung von Isolation-(Mocking-)Frameworks wie Moq, FakeItEasy und Typemock Isolator erlernen. Sie erfahren eine Menge zu Testmustern und zur Testorganisation, führen Refactoring durch und lernen, wie man »untestbaren« Code testet. Nebenbei zeigt Ihnen der Autor das Integration Testing sowie Techniken zum Testen mit Datenbanken. Die Beispiele im Buch verwenden C#, sind aber auch für jeden nützlich, der eine Sprache mit statischen Typen wie Java oder C++ benutzt. Aus dem Inhalt: Grundlagen des Unit Testings Frameworks für das Unit Testing Einsatz von NUnit Stubs zum Auflösen von Abhängigkeiten Interaction Testing mit Mock-Objekten Isolation-(Mocking-)Frameworks Testhierarchie und Organisation Die Säulen guter Unit Tests Integration von Unit Tests in das Unternehmen Umgang mit Legacy Code Design und Testbarkeit Tools und Frameworks Stimmen zum Buch: »Dieses Buch ist etwas Besonderes. Die Kapitel bauen aufeinander auf und entwickeln eine erstaunliche Tiefe.« – Aus dem Vorwort von Robert C. Martin, cleancoder.com »Die beste Art, Unit Testing zu lernen. Bereits ein Klassiker auf dem Gebiet.« – Raphael Faria, LG Electronics »Bringt Ihnen sowohl die Philosophie des effektiven Unit Testings bei als auch die praktischen Grundlagen.« – Pradeep Chellappan, Microsoft »Wenn meine Teammitglieder fragen, wie sie Unit Tests richtig schreiben sollen, antworte ich einfach: mit diesem Buch!« – Alessandro Campeis, Vimar SpA
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 465
Veröffentlichungsjahr: 2015
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
The Art of Unit Testing
Deutsche Ausgabe
Roy Osherove
Übersetzung aus dem Englischen von Olaf Neuendorf
Impressum
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über <http://dnb.d-nb.de> abrufbar.
ISBN 978-3-8266-8722-8
2. Auflage 2015
www.mitp.de
E-Mail: [email protected]
Telefon: +49 7953 / 7189 - 079
Telefax: +49 7953 / 7189 - 082
Übersetzung der amerikanischen Originalausgabe: Roy Osherove: The Art of Unit Testing: With Examples in C#, Second Edition, ISBN 978-1617290893.
Original English language edition published by Manning Publications, 178 South Hill Drive, Westampton, NJ 08060 USA. Copyright © 2013 by Manning Publications. German edition copyright © 2015 by mitp Verlags GmbH & Co. KG. All rights reserved.
© 2015 mitp-Verlags GmbH & Co. KG
Dieses Werk, einschließlich aller seiner Teile, ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.
Lektorat: Sabine Schulz
Sprachkorrektorat: Petra Heubach-Erdmann, Maren Feilen
Coverbild: © Sebastian Duda, Bildnummer 33776850
electronic publication: III-satz, Husby, www.drei-satz.de
Dieses Ebook verwendet das ePub-Format und ist optimiert für die Nutzung mit dem iBooks-reader auf dem iPad von Apple. Bei der Verwendung anderer Reader kann es zu Darstellungsproblemen kommen.
Der Verlag räumt Ihnen mit dem Kauf des ebooks das Recht ein, die Inhalte im Rahmen des geltenden Urheberrechts zu nutzen. Dieses Werk, einschließlich aller seiner Teile, ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheherrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und Einspeicherung und Verarbeitung in elektronischen Systemen.
Der Verlag schützt seine ebooks vor Missbrauch des Urheberrechts durch ein digitales Rechtemanagement. Bei Kauf im Webshop des Verlages werden die ebooks mit einem nicht sichtbaren digitalen Wasserzeichen individuell pro Nutzer signiert.
Bei Kauf in anderen ebook-Webshops erfolgt die Signatur durch die Shopbetreiber. Angaben zu diesem DRM finden Sie auf den Seiten der jeweiligen Anbieter.
Vorwort zur zweiten Auflage
Es muss im Jahre 2009 gewesen sein. Ich hielt einen Vortrag auf der Norwegian Developers Conference in Oslo. (Ah, Oslo im Juni!) Die Veranstaltung fand in einer großen Sportarena statt. Die Konferenz-Organisatoren unterteilten die überdachte Tribüne in Abschnitte und bauten jeweils ein Podium vor ihnen auf. Dann hängten sie dicke schwarze Stoffbahnen auf und erstellten auf diese Weise acht verschiedene »Konferenzräume«. Ich erinnere mich, dass ich gerade dabei war, meinen Vortrag zu beenden – er handelte von TDD, oder SOLID, oder Astronomie, oder irgendwas – als plötzlich von der Nachbarbühne ein lautes und raues Singen und Gitarrenspiel ertönte.
Die Stoffbahnen hingen so, dass ich zwischen ihnen hindurch spähen und den Burschen auf der Nachbarbühne sehen konnte. Natürlich war es Roy Osherove.
Nun, diejenigen von Ihnen, die mich kennen, wissen, dass das Anstimmen eines Liedes mitten in einem technischen Vortrag über Software zu den Dingen gehört, die ich vielleicht tue, wenn mir danach ist. Als ich mich wieder meinem Publikum zuwandte, dachte ich so bei mir, dass dieser Osherove wohl ein Gleichgesinnter sei und ich ihn besser kennenlernen müsse.
Und ich lernte ihn besser kennen. In der Tat trug er erheblich zu meinem aktuellen Buch Clean Coder bei und unterstützte mich drei Tage lang dabei, einen Kurs in TDD zu geben. Alle meine Erfahrungen mit Roy waren sehr positiv und ich hoffe, es wird noch viele weitere geben.
Ich schätze, dass Ihre Erfahrungen mit Roy beim Lesen dieses Buch auch sehr positiv sein werden, denn dieses Buch ist etwas Besonderes.
Haben Sie jemals einen Roman von Michener gelesen? Ich jedenfalls nicht – aber mir wurde gesagt, sie alle würden »mit dem Atom« beginnen. Das Buch, das Sie in Händen halten, ist kein James-Michener-Roman, aber es beginnt mit dem Atom – dem Atom des Unit Testings.
Lassen Sie sich nicht beirren, wenn Sie die ersten Seiten durchblättern. Dies ist keine bloße Einführung ins Unit Testing. Es beginnt so, aber wenn Sie bereits Erfahrung haben, können Sie diese ersten Kapitel schnell überfliegen. Während das Buch dann aber voranschreitet, beginnen die Kapitel aufeinander aufzubauen und entwickeln eine erstaunliche Tiefe. Und als ich das letzte Kapitel las (ich wusste nicht, dass es das letzte war), dachte ich tatsächlich, dass das nächste wohl vom Weltfrieden handeln müsse – denn im Ernst, womit sonst kann man weitermachen, nachdem man das Problem gelöst hat, Unit Testing in starrsinnige Organisationen mit alten, überkommenen Systemen einzuführen.
Dieses Buch ist ein Fachbuch – und zutiefst ein Fachbuch. Es gibt eine Menge Code. Und das ist gut so. Doch Roy beschränkt sich nicht auf die technischen Aspekte. Gelegentlich holt er seine Gitarre hervor, beginnt zu singen und erzählt Geschichten aus seinem Berufsleben. Oder er stellt philosophische Betrachtungen an über die Bedeutung von Design oder die Definition von Integration. Er scheint Gefallen daran zu finden, uns mit Geschichten aus jenen dunklen, längst vergangenen Tagen des Jahres 2006 zu verwöhnen, als ihm so manches misslungen ist.
Ach, und machen Sie sich keine allzu großen Sorgen, dass der komplette Code in C# geschrieben ist. Im Ernst, wer könnte überhaupt den Unterschied zwischen C# und Java erklären? Oder? Und abgesehen davon spielt es auch keine Rolle. Er mag zwar C# als Vehikel benutzen, um seine Intention klar zu machen, aber die Lektionen in diesem Buch gelten genauso für Java, C, Ruby, Python, PHP oder jede andere Programmiersprache (vielleicht mit Ausnahme von COBOL).
Egal, ob Sie ein Anfänger auf dem Gebiet des Unit Testings und der testgetriebenen Entwicklung sind oder ein alter Hase, dieses Buch hält für Sie alle etwas bereit. Also viel Vergnügen, während Roy für Sie sein Lied singt »The Art of Unit Testing«.
Und bitte Roy, stimme diese Gitarre!
Robert C. Martin (Uncle Bob)CLEANCODER.COM
Vorwort zur ersten Auflage
Als mir Roy Osherove erzählte, er würde an einem Buch über das Unit Testing arbeiten, war ich sehr froh, dies zu hören. Das Test-Mem ist über die Jahre in der Industrie gewachsen, aber es gibt einen relativen Mangel an Material zum Unit Testing. Wenn ich mein Bücherregal betrachte, dann sehe ich Bücher zur testgetriebenen Entwicklung im Besonderen und Bücher zum Testen im Allgemeinen, aber bis jetzt gab es keine umfassende Referenz zum Unit Testing – kein Buch, das in das Thema einführt, den Leser an die Hand nimmt und von den ersten Schritten bis zu den allgemein akzeptierten besten Vorgehensweisen führt. Diese Tatsache ist verblüffend. Unit Testing ist keine neue Praxis. Wie konnte es dazu kommen?
Es ist beinahe ein Klischee, wenn man sagt, dass wir in einer neuen Industrie arbeiten, aber es ist wahr. Mathematiker legten die Grundlagen unserer Arbeit vor weniger als 100 Jahren, aber erst seit 60 Jahren haben wir die Hardware, die schnell genug ist, um ihre Erkenntnisse auch nutzen zu können. In unserer Industrie bestand von Anfang an eine Lücke zwischen Theorie und Praxis und erst jetzt entdecken wir, wie sich das auf unser Fachgebiet ausgewirkt hat.
In den frühen Jahren waren Rechenzeiten teuer. Wir ließen die Programme im Batchbetrieb laufen. Programmierer hatten ein planmäßiges Zeitfenster, sie mussten ihre Programme in Kartenstapel stanzen und in den Maschinenraum tragen. War ein Programm nicht in Ordnung, hatten sie ihre Zeit vergeudet, also überprüften sie es zuvor mit Papier und Stift am Schreibtisch und gingen in Gedanken alle möglichen Szenarien, alle Grenzfälle durch. Ich bezweifle, dass der Begriff des automatisierten Unit Testings zu dieser Zeit überhaupt vorstellbar war. Warum sollte man die Maschine zum Testen nutzen, wo sie doch zur Lösung bestimmter Probleme gebaut worden war? Der Mangel hielt uns in der Dunkelheit gefangen.
Später wurden die Maschinen schneller und wir berauschten uns am interaktiven Computing. Wir konnten einfach Code eintippen und ihn aus Jux und Tollerei ändern. Die Idee, den Code am Schreibtisch zu überprüfen, schwand allmählich dahin und wir verloren etwas von der Disziplin der frühen Jahre. Wir wussten, dass Programmieren schwierig war, aber das bedeutete nur, dass wir mehr Zeit am Computer verbringen mussten und Zeilen und Symbole änderten, bis wir die magische Zauberformel, die funktionierte, gefunden hatten.
Wir kamen vom Mangel zum Überfluss und verpassten den Mittelweg, aber nun erobern wir ihn zurück. Automatisiertes Unit Testing verbindet die Disziplin der Schreibtischprüfung mit einer neu gefundenen Wertschätzung des Computers als einer Entwicklungsressource. Wir können automatische Tests in der Sprache schreiben, in der wir entwickeln, um unsere Arbeit zu überprüfen – und das nicht nur einmal, sondern so oft wir in der Lage sind, die Tests laufen zu lassen. Ich glaube nicht, dass es irgendein anderes Verfahren in der Softwareentwicklung gibt, das derartig mächtig ist.
Während ich dies im Jahre 2009 schreibe, bin ich froh zu sehen, wie Roys Buch in den Druck geht. Es ist eine praktische Anleitung, die Ihnen helfen wird, loszulegen, und es ist auch eine großartige Referenz, wenn Sie Ihre Aufgaben beim Testing angehen. The Art of Unit Testing ist kein Buch über idealisierte Szenarien. Es zeigt Ihnen, wie man Code testet, der im praktischen Einsatz existiert, wie man Nutzen aus weitverbreiteten Frameworks zieht und – was das Wichtigste ist – wie man Code schreibt, der wesentlich einfacher zu testen ist.
The Art of Unit Testing ist ein wichtiger Titel, der schon vor Jahren hätte geschrieben werden sollen, aber damals waren wir noch nicht bereit dafür. Jetzt sind wir bereit. Genießen Sie es!
Michael Feathers
Senior Consultant Object Mentor
Einleitung
Eines der größten Projekte, an dem ich mitgearbeitet habe und das schiefgelaufen ist, beinhaltete auch Unit Tests. Das dachte ich zumindest. Ich leitete eine Gruppe von Entwicklern, die an einer Abrechnungssoftware arbeiteten, und wir machten es komplett auf die testgetriebene Weise – wir schrieben zuerst die Tests, dann den Code, die Tests schlugen fehl, wir sorgten dafür, dass sie erfolgreich verliefen, führten ein Refactoring durch und fingen wieder von vorne an.
Die ersten paar Monate des Projekts waren großartig. Alles lief gut und wir hatten Tests, die belegten, dass unser Code funktionierte. Aber im Laufe der Zeit änderten sich die Anforderungen. Wir waren also gezwungen, unseren Code zu ändern, um diesen neuen Anforderungen gerecht zu werden, doch als wir das taten, wurden die Tests unzuverlässig und mussten nachgebessert werden. Der Code funktionierte immer noch, aber die Tests, die wir dafür geschrieben hatten, waren so zerbrechlich, dass jede kleine Änderung in unserem Code sie überforderte, auch wenn der Code selbst prima funktionierte. Die Änderung des Codes in einer Klasse oder Methode wurde zu einer gefürchteten Aufgabe, weil wir auch alle damit zusammenhängenden Unit Tests entsprechend anpassen mussten.
Schlimmer noch, einige Tests wurden sogar unbrauchbar, weil diejenigen, die sie geschrieben hatten, das Projekt verließen und keiner wusste, wie deren Tests zu pflegen waren oder was sie eigentlich testeten. Die Namen, die wir unseren Unit-Testing-Methoden gaben, waren nicht aussagekräftig genug und wir hatten Tests, die auf anderen Tests aufbauten. Schließlich warfen wir nach weniger als sechs Monaten Projektlaufzeit die meisten der Tests wieder hinaus.
Das Projekt war ein erbärmlicher Fehlschlag, weil wir zugelassen hatten, dass die Tests, die wir schrieben, mehr schadeten als nützten. Langfristig brauchten wir mehr Zeit, um sie zu pflegen und zu verstehen, als sie uns einsparten. Also hörten wir auf, sie einzusetzen. Ich machte mit anderen Projekten weiter und dort haben wir unsere Arbeit beim Schreiben der Unit Tests besser erledigt. Ihr Einsatz brachte uns großen Erfolg und sparte eine Menge Zeit beim Debuggen und bei der Integration. Seitdem dieses erste Projekt fehlschlug, trage ich bewährte Vorgehensweisen für das Unit Testing zusammen und wende sie auch im nachfolgenden Projekt an. Im Laufe jedes Projekts, an dem ich arbeite, entdecke ich weitere gute Vorgehensweisen.
Zu verstehen, wie man Unit Tests schreibt – und wie man sie wartbar, lesbar und vertrauenswürdig macht –, ist das, wovon dieses Buch handelt. Egal, welche Sprache oder welche integrierte Entwicklungsumgebung (IDE) Sie verwenden. Dieses Buch behandelt die Grundlagen für das Schreiben von Unit Tests, geht dann auf die Grundlagen des Interaction Testings ein und stellt schließlich bewährte Vorgehensweisen für das Schreiben, das Verwalten und das Warten der Unit Tests in echten Projekten vor.
Über dieses Buch
Dass man das, was man wirklich lernen möchte, unterrichten sollte, ist das vielleicht Klügste, was ich jemals irgendwen über das Lernen sagen hörte (ich vergaß, wer das war). Das Schreiben und Veröffentlichen der ersten Ausgabe dieses Buches im Jahre 2009 war nicht weniger als eine echte Lehre für mich. Ursprünglich schrieb ich das Buch, weil ich keine Lust mehr hatte, die gleichen Fragen immer wieder zu beantworten. Aber natürlich gab es auch andere Gründe. Ich wollte etwas Neues ausprobieren, ich wollte experimentieren, ich wollte herausfinden, was ich lernen konnte, indem ich ein Buch schrieb – irgendein Buch. Im Bereich Unit Testing war ich gut. Dachte ich. Aber es ist ein Fluch: Je mehr Erfahrung man hat, desto dümmer kommt man sich vor.
Es gibt Teile in der ersten Ausgabe, denen ich heute nicht mehr zustimme – bespielsweise, dass sich eine Unit auf eine Methode bezieht. Das ist einfach nicht richtig. Eine Unit ist eine Arbeitseinheit, was ich in Kapitel 1 dieser zweiten Auflage diskutiere. Sie kann so klein sein wie eine Methode oder so groß wie mehrere Klassen (möglicherweise Assemblies). Und wie Sie noch sehen werden, gibt es weitere Dinge, die sich ebenfalls geändert haben.
Was neu ist in der zweiten Auflage
In dieser zweiten Auflage habe ich Material über die Unterschiede zwischen beschränkten und unbeschränkten Isolation-Frameworks hinzugefügt. Es gibt ein neues Kapitel 6, das sich mit der Frage beschäftigt, was ein gutes Isolation-Framework ausmacht und wie ein Framework wie Typemock im Inneren funktioniert.
Ich verwende RhinoMocks nicht mehr. Lassen Sie die Finger davon. Es ist tot. Zumindest für den Augenblick. Ich benutze NSubstitute für Beispiele zu den Grundlagen von Isolation-Frameworks und ich empfehle auch FakeItEasy. Ich bin immer noch nicht begeistert von MOQ, was ich detaillierter in Kapitel 6 erläutern werde.
Dem Kapitel über die Implementation des Unit Testings auf der Organisationsebene habe ich weitere Techniken hinzugefügt.
Es gibt eine Reihe von Design-Änderungen im Code, der in diesem Buch abgedruckt ist. Meist habe ich aufgehört, Property Setters zu verwenden, und benutze häufig Constructor Injection. Einige Diskussionen zu den Prinzipien von SOLID habe ich hinzugefügt – aber nur so viel, um Ihnen Appetit auf das Thema zu machen.
Die auf das Build bezogenen Teile von Kapitel 7 enthalten ebenfalls neue Informationen. Seit dem ersten Buch habe ich eine Menge zur Build-Automatisierung und zu Mustern gelernt.
Ich rate von Setup-Methoden ab und stelle Alternativen vor, um Ihre Test mit der gleichen Funktionalität auszustatten. Ich benutze auch neuere Versionen von Nunit, sodass sich einige der neueren Nunit APIs in diesem Buch geändert haben.
Den Teil von Kapitel 10, der sich mit Tools im Hinblick auf Legacy-Code beschäftigt, habe ich aktualisiert.
Die Tatsache, dass ich in den letzten drei Jahren neben .NET mit Ruby gearbeitet habe, führte bei mir zu neuen Einsichten in Bezug auf Design und Testbarkeit. Das spiegelt sich in Kapitel 11 wider. Den Anhang zu Werkzeugen und Frameworks habe ich aktualisiert, neue Tools hinzugefügt und alte entfernt.
Wer dieses Buch lesen sollte
Dieses Buch ist für jeden geeignet, der Code entwickelt und daran interessiert ist, die besten Methoden für das Unit Testing zu erlernen. Alle Beispiele sind mit Visual Studio in C# geschrieben, weshalb die Beispiele insbesondere für .NET-Entwickler nützlich sein werden. Aber was ich unterrichte, passt genau so gut auf die meisten, wenn nicht auf alle objektorientierten und statisch typisierten Sprachen (VB.NET, Java und C++, um nur ein paar zu nennen). Egal, ob Sie ein Architekt sind, ein Entwickler, ein Teamleiter, ein QS-Mitarbeiter (der Code schreibt) oder ein Anfänger in der Programmierung, dieses Buch wurde für Sie geschrieben.
Meilensteine
Wenn Sie noch nie einen Unit Test geschrieben haben, dann ist es am besten, Sie lesen das Buch vom Anfang bis zum Ende, um das komplette Bild zu erhalten. Wenn Sie aber schon Erfahrung haben, dann fühlen Sie sich frei, so in den Kapiteln zu springen, wie es Ihnen gerade passt. Das vorliegende Buch ist in vier Hauptteile gegliedert.
Teil I bringt Sie beim Schreiben von Unit Tests von 0 auf 100. Kapitel 1 und 2 beschäftigen sich mit den Grundlagen, wie etwa der Verwendung eines Test-Frameworks (NUnit), und führen die grundlegenden Testattribute ein, wie z. B. [Test] und [TestCase]. Darüber hinaus werden hier auch verschiedene Prinzipien erläutert im Hinblick auf die Assertion, das Ignorieren von Tests, das Testen von Arbeitseinheiten (Unit of Work Testing), die drei Typen von Endergebnissen eines Unit Tests und der drei dazu benötigten Arten von Tests, nämlich Value Tests, State-Based Tests und Interaction Tests.
Teil II diskutiert fortgeschrittene Methoden zum Auflösen von Abhängigkeiten: Mock-Objekte, Stubs, Isolation-Frameworks und Muster zum Refactoring Ihres Codes, um diese nutzen zu können. Kapitel 3 stellt das Konzept der Stubs vor und veranschaulicht, wie man sie von Hand erzeugen und benutzen kann. In Kapitel 4 wird das Interaction Testing mit handgeschriebenen Mock-Objekten beschrieben. Kapitel 5 führt diese beiden Konzepte schließlich zusammen und zeigt, wie sie sich mithilfe von Isolation-(Mock-)Frameworks kombinieren lassen und ihre Automatisierung erlauben. Kapitel 6 vertieft das Verständnis für beschränkte und unbeschränkte Isolation-Frameworks und wie sie unter der Haube funktionieren.
Teil III beschäftigt sich mit verschiedenen Möglichkeiten, den Testcode zu organisieren, mit Mustern, um ihn auszuführen und seine Strukturen umzubauen (Refactoring), und mit bewährten Methoden zum Schreiben von Tests. In Kapitel 7 werden Testhierarchien vorgestellt und es wird dargestellt, wie Testinfrastruktur-APIs verwendet und wie Tests in den automatisierten Build-Prozess eingebunden werden. Kapitel 7 diskutiert bewährte Vorgehensweisen beim Unit Testing, um wartbare, lesbare und vertrauenswürdige Tests zu entwickeln.
Teil IV beschäftigt sich damit, wie sich Veränderungen in einer Organisation umsetzen lassen und wie man mit existierendem Code umgehen kann. In Kapitel 9 werden Probleme und Lösungen im Zusammenhang mit der Einführung des Unit Testings in einem Unternehmen diskutiert. Dabei werden auch einige Fragen beantwortet, die Ihnen in diesem Zusammenhang vielleicht gestellt werden. Kapitel 10 behandelt die Integration des Unit Testings in vorhandenen Legacy-Code. Es werden mehrere Möglichkeiten aufgezeigt, um festzulegen, wo mit dem Testen begonnen werden sollte, und es werden mehrere Tools vorgestellt, um »untestbaren« Code zu testen. Kapitel 11 diskutiert das vorbelastete Thema des Designs um der Testbarkeit willen und die Alternativen, die derzeit existieren.
Der Anhang listet eine Reihe von Tools auf, die Sie bei Ihren Testanstrengungen hilfreich finden könnten.
Codekonventionen und Downloads
Sie können den Quellcode von der Verlagsseite unter www.mitp.de/9712 herunterladen. Hier finden Sie den Quellcode so wie er in diesem Buch abgedruckt ist (bitte beachten Sie hier auch die Readme-Datei zu den verschiedenen Versionen des Visual Studios). Den Quellcode des Originalbuches können Sie auch auf den folgenden Webseiten herunterladen: https://github.com/royosherove/aout2, www.ArtOfUnitTesting.com oder www.manning.com/osherove2, wo Sie auch weitere englischsprachige Informationen zum Buch, zu dessen Themen und zum Autor finden.
Sämtliche in diesem Buch enthaltenen Listings sind vom normalen Text klar zu unterscheiden und in einer anderen Schriftart wie dieser gesetzt. Manche Passagen sind fett gedruckt, um sie besonders hervorzuheben, oder auch mit einem besonderen Hinweissymbol gekennzeichnet, wenn sie gesondert referenziert werden. [1]
Softwareanforderungen
Um den Code in diesem Buch benutzen zu können, benötigen Sie zumindest Visual Studio C# Express (das kostenlos ist) oder die umfangreicheren (und kostenpflichtigen) Versionen [2]. Darüber hinaus sind auch NUnit (ein freies Open-Source-Framework) und andere Tools erforderlich, auf die an den entsprechenden Stellen hingewiesen wird. Alle erwähnten Tools sind entweder kostenlos, als Open-Source-Versionen oder aber als Testversionen verfügbar, die Sie ausprobieren können, während Sie dieses Buch lesen.
Danksagung
Ein großes Dankeschön geht an Michael Stephens und Nermina Miller von Manning Publications für ihre Geduld auf dem langen Weg beim Schreiben dieses Buches. Mein Dank geht ebenso an jeden bei Manning, der an der zweiten Auflage in der Produktion und hinter den Kulissen mitgearbeitet hat.
Dank gebührt auch Jim Newkirk, Michael Feathers, Gerard Meszaros und vielen anderen, die mich mit Inspiration und Ideen unterstützt und dieses Buch zu dem gemacht haben, was es ist. Besonders danke ich dir, Uncle Bob Martin, dafür, dass du es übernommen hast, das Vorwort für die zweite Auflage zu schreiben.
Die folgenden Rezensenten haben das Manuskript in verschiedenen Phasen seiner Entwicklung gelesen. Ich möchte ihnen für ihre wertvollen Anmerkungen danken: Aaron Colcord, Alessandro Campeism, Alessandro Gallo, Bill Sorensen, Bruno Sonnino, Camal Cakar, David Madouros, Dr. Frances Buontempo, Dror Helper, Francesco Goggi, Iván Pazmino, Jason Hales, Joao Angelo, Kaleb Pederson, Karl Metivier, Mertin Skurla, Martyn Fletcher, Paul Stack, Philip Lee, Pradeep Chellappan, Raphael Faria und Tim Sloan. Dank auch an Rickard Nilsson, der das abschließende Manuskript vor der Drucklegung Korrektur gelesen hat.
Ein abschließendes Wort des Dankes auch an die ersten Leser des Buches in Mannings »Early Access Program« für ihre Kommentare im Online-Forum. Sie haben dabei geholfen, dem Buch seine endgültige Form zu geben.
[1] Anmerkung des Übersetzers: Die Kommentare innerhalb der Listings und auch der größte Teil der Strings wurden – der größeren Klarheit und der besseren Lesbarkeit wegen – übersetzt. In dieser Hinsicht unterscheiden sich die abgedruckten Listings vom englischen Quelltext, den Sie von den amerikanischen Webseiten herunterladen können. Der Quelltext auf der deutschen Seite des mitp-Verlages wurde genauso angepasst, wie Sie ihn in diesem Buch vorfinden. Sie haben also die Möglichkeit, wahlweise die unveränderten Original-Dateien von den amerikanischen Seiten oder die überarbeiteten von der deutschen Seite zu verwenden.
[2] Anmerkung des Übersetzers: Zum Zeitpunkt der Veröffentlichung des amerikanischen Originaltitels war VS 2010 die aktuelle Version von Microsoft, auf die auch in diesem Buch Bezug genommen wurde. Hier wurden in der vorliegenden deutschen Ausgabe Verweise auf die inzwischen veröffentlichte Version 2013 ergänzt oder ersetzt. Beachten Sie bitte auch die der deutschen Version des Quellcodes beiliegende Readme-Datei, die Hinweise auf die verschiedenen Versionen enthält.
Teil I: Erste Schritte
Dieser Teil des Buches behandelt die Grundlagen des Unit Testings.
In Kapitel 1 werde ich definieren, was eine Unit ist und was »gutes« Unit Testing bedeutet und ich werde das Unit Testing mit dem Integration Testing vergleichen. Anschließend werfen wir einen kurzen Blick auf das Test-Driven Development und dessen Rolle in Bezug auf das Unit Testing.
In Kapitel 2 werden Sie damit loslegen, Ihren ersten Unit Test mithilfe von NUnit zu schreiben. Sie werden die grundlegende API von NUnit kennenlernen und Sie werden sehen, wie Asserts verwendet und wie Tests mit dem NUnit Test Runner durchgeführt werden.
In diesem Teil:
Kapitel 1
Die Grundlagen des Unit Testings
Kapitel 2
Ein erster Unit Test
