The Art of Unit Testing

Transkript

1 The Art of Unit Testing Deutsche Ausgabe von Roy Osherove, Michael Feathers, Robert C. Martin 1. Auflage The Art of Unit Testing Osherove / Feathers / Martin schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG Thematische Gliederung: Softwaretests & Prüfsoftware mitp/bhv 2010 Verlag C.H. Beck im Internet: ISBN

2 Lesbare, wartbare und zuverlässige Tests entwickeln Stubs, Mock-Objekte und automatisierte Frameworks Einsatz von.net-tools inkl. NUnit, Rhino Mocks und Typemock Isolator Außerdem zum Thema bei mitp: Osherove Roy Osherove Aus dem Inhalt: Verwenden eines Test- Frameworks (NUnit) Grundlegende Testattribute Stubs zum Auflösen von Abhängigkeiten Interaction Testing mit Mock-Objekten Testhierarchie und Organisation Die Säulen guter Tests Integration von Unit Testing in das Unternehmen Umgang mit Legacy Code Über den Autor: Roy Osherove ist Chef- Architekt bei Typemock und war von Anfang an einer der Organisatoren von ALT.NET. Er berät und trainiert Teams weltweit in der Kunst des Unit Testings sowie der testgetriebenen Entwicklung. Er spricht regelmäßig auf internationalen Konferenzen wie TechEd oder JAOO. Roys Blog finden Sie auf ISerializable.com. Unit Testing, richtig durchgeführt, kann den Unterschied ausmachen zwischen einem fehlgeschlagenen Projekt und einem erfolgreichen, zwischen einer wartbaren Code-Basis und einer, die niemand freiwillig anpackt, zwischen dem Nach-Hause- Kommen um 2 Uhr nachts oder zum Abendessen, selbst noch kurz vor dem Release-Termin. Roy Osherove führt Sie Schritt für Schritt von einfachen Tests zu Tests, die wartbar, lesbar und zuverlässig sind. Er geht danach 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. Darüber hinaus werden auch fortgeschrittene Themen behandelt wie Mocks, Stubs und Frameworks wie etwa Typemock Isolator und Rhino Mocks. Sie werden eine Menge zu fortgeschrittenen Testmustern und zur Testorganisation, zum Arbeiten mit Legacy Code und auch zu untestbarem Code erfahren. Und Sie lernen Werkzeuge kennen, die Sie beim Testen von Datenbanken und anderen Technologien brauchen werden. Die Beispiele sind in C# erstellt, aber auch für Programmierer anderer Sprachen wird das Buch von großem Nutzen sein, da die Prinzipien des Unit Testings für andere Sprachen dieselben sind. Stimmen zum Buch:»Ein wichtiges Buch, das schon vor Jahren hätte geschrieben werden sollen.«aus dem Vorwort von Michael Feathers»Jedes bisher zum Unit Testing geschriebene Buch war für Amateure. Dieses hier ist für Profis.«Josh Cronemeyer, ThoughtWorks»Nehmen Sie Handwerkskunst ernst? Dann müssen Sie dieses Buch haben.«dave Nicolette, Independent Agile Coach»Eine gründliche, schrittweise Einführung und [ ] Ideen zur Weiterentwicklung [Ihrer] Arbeitsweise.«Kent Beck, Three Rivers Institute ISBN ISBN ISBN Unit Testing The Art of Unit Testing Deutsche Ausgabe ISBN ISBN (D) 39, _umschlag.indd :07:24

3 book Seite 5 Donnerstag, 4. November :02 18 Vorwort Einleitung Über dieses Buch Wie Sie dieses Buch verwenden Wer dieses Buch lesen sollte Meilensteine Codekonventionen und Downloads Softwareanforderungen Danksagung Teil I Erste Schritte Die Grundlagen des Unit Testings Unit Testing Die klassische Definition Die Bedeutung»guter«Unit Tests Wir alle haben schon Unit Tests geschrieben (irgendwie) Eigenschaften eines»guten«unit Tests Integration Tests Nachteile von Integration Tests im Vergleich zu automatisierten Unit Tests »Gute«Unit Tests Eine Definition Ein einfaches Unit-Test-Beispiel Testgetriebene Entwicklung Zusammenfassung Ein erster Unit Test Frameworks für das Unit Testing Was Unit Testing Frameworks bieten Die xunit Frameworks Das LogAn-Projekt wird vorgestellt

4 book Seite 6 Donnerstag, 4. November : Die ersten Schritte mit NUnit Die Installation von NUnit Das Laden der Projektmappe Die Verwendung der NUnit-Attribute in Ihrem Code Wir schreiben unseren ersten Test Die Klasse Assert Wir führen unseren ersten Test mit NUnit aus Fehlerbehebung und ein erfolgreicher Testlauf Von Rot nach Grün Weitere NUnit-Attribute Aufbau und Abbau Auf erwartete Ausnahmen prüfen Das Ignorieren von Tests Das Festlegen der Testkategorien Indirekte Zustandstests Zusammenfassung Teil II Zentrale Methoden Die Verwendung von Stubs, um Abhängigkeiten aufzulösen Die Stubs werden vorgestellt Die Identifizierung einer Dateisystemabhängigkeit in LogAn Die Entscheidung, wie LogAnalyzer am einfachsten getestet werden kann Design-Refactoring zur Verbesserung der Testbarkeit Extrahiere ein Interface, um die dahinter liegende Implementierung durch eine andere ersetzen zu können Injiziere eine Stub-Implementierung in die zu testende Klasse Übergebe dem Konstruktor ein Interface (Constructor Injection) Übergebe einer Property ein Interface Hole einen Stub unmittelbar vor einem Methodenaufruf Variationen der Refactoring-Technik Die Verwendung von Extract and Override, um Stub-Resultate zu erzeugen

5 book Seite 7 Donnerstag, 4. November : Die Überwindung des Kapselungsproblems Die Verwendung von internal und [InternalsVisibleTo] Die Verwendung des Attributs [Conditional] Die Verwendung von #if und #endif zur bedingten Kompilierung Zusammenfassung Interaction Testing mit Mock-Objekten Zustandsbasiertes Testen gegenüber Interaction Testing Der Unterschied zwischen Mocks und Stubs Ein einfaches manuelles Mock-Beispiel Die gemeinsame Verwendung von Mock und Stub Ein Mock pro Test Stub-Ketten: Stubs, die Mocks oder andere Stubs erzeugen Die Probleme mit handgeschriebenen Mocks und Stubs Zusammenfassung Isolation (Mock-Objekt-)Frameworks Warum überhaupt Isolation Frameworks? Das dynamische Erzeugen eines Fake-Objekts Die Einführung von Rhino Mocks in Ihre Tests Das Ersetzen eines handgeschriebenen Mock-Objekts durch ein dynamisches Strikte und nicht-strikte Mock-Objekte Strikte Mocks Nicht-strikte Mocks Die Rückgabe von Werten aus Fake-Objekten Das Erzeugen schlauer Stubs mit einem Isolation Framework Das Erzeugen eines Stubs in Rhino Mocks Die Kombination von dynamischen Stubs und Mocks Parameter Constraints für Mocks und Stubs Das Überprüfen von Parametern mit String Constraints Das Überprüfen von Parameter Object Properties mit Constraints Die Ausführung von Callbacks zur Parameterverifikation Das Testen auf Event-bezogene Aktivitäten Wir testen, ob ein Event abonniert wurde Das Triggern von Events aus Mocks und Stubs heraus Wir testen, ob ein Event ausgelöst wurde

6 book Seite 8 Donnerstag, 4. November : Die Arrange-Act-Assert-Syntax für die Isolation Die aktuellen Isolation Frameworks für.net NUnit.Mocks NMock NMock Typemock Isolator Rhino Mocks Moq Die Vorteile von Isolation Frameworks Mögliche Fallstricke bei der Verwendung von Isolation Frameworks Unlesbarer Testcode Die Verifizierung der falschen Dinge Die Verwendung von mehr als einem Mock pro Test Die Überspezifizierung von Tests Zusammenfassung Teil III Der Testcode Testhierarchie und Organisation Mit automatisierten Builds automatisierte Tests laufen lassen Die Anatomie eines automatisierten Builds Das Anstoßen von Builds und die kontinuierliche Integration Automatisierte Build-Typen Testentwürfe, die auf Geschwindigkeit und Typ basieren Der menschliche Faktor beim Trennen von Unit und Integration Tests Die sichere grüne Zone Stellen Sie sicher, dass die Tests zu Ihrer Quellcodekontrolle gehören Das Abbilden der Testklassen auf den zu testenden Code Das Abbilden von Tests auf Projekte Das Abbilden von Tests auf Klassen Das Abbilden von Tests auf bestimmte Methoden Wir bauen eine Test-API für Ihre Applikation Die Verwendung von Testklassen-Vererbungsmustern

7 book Seite 9 Donnerstag, 4. November : Der Entwurf von Test-Hilfsklassen und -Hilfsmethoden Machen Sie Ihre API den Entwicklern bekannt Zusammenfassung Die Säulen guter Tests Das Schreiben vertrauenswürdiger Tests Die Entscheidung, wann Tests entfernt oder geändert werden Vermeiden Sie Logik in Tests Testen Sie nur eine Sache Machen Sie es leicht, die Tests auszuführen Stellen Sie die Code-Abdeckung sicher Das Schreiben wartbarer Tests Das Testen privater oder geschützter Methoden Das Entfernen von Duplizitäten Die Verwendung von Setup-Methoden in einer wartbaren Art und Weise Das Erzwingen der Test-Isolierung Vermeiden Sie mehrfache Asserts Vermeiden Sie es, mehrere Aspekte des gleichen Objekts zu testen Vermeiden Sie eine Überspezifizierung der Tests Das Schreiben lesbarer Tests Die Benennung der Unit Tests Die Benennung der Variablen Benachrichtigen Sie sich sinnvoll Das Trennen der Asserts von den Aktionen Aufbauen und Abreißen Zusammenfassung Teil IV Design und Durchführung Die Integration von Unit Tests in das Unternehmen Schritte, um ein Agent des Wandels zu werden Seien Sie auf die schweren Fragen vorbereitet Überzeugen Sie Insider: Champions und Blockierer Identifizieren Sie mögliche Einstiegspunkte

8 book Seite 10 Donnerstag, 4. November : Wege zum Erfolg Guerilla-Implementierung (Bottom-up) Überzeugen Sie das Management (Top-down) Holen Sie einen externen Champion Machen Sie Fortschritte sichtbar Streben Sie bestimmte Ziele an Machen Sie sich klar, dass es Hürden geben wird Wege zum Misserfolg Mangelnde Triebkraft Mangelnde politische Unterstützung Schlechte Implementierungen und erste Eindrücke Mangelnde Teamunterstützung Schwierige Fragen und Antworten Wie viel zusätzliche Zeit wird für den aktuellen Prozess benötigt? Ist deswegen mein Job bei der QS in Gefahr? Woher wissen wir, dass es wirklich funktionieren wird? Gibt es denn einen Beweis, dass Unit Testing hilft? Warum findet die QS immer noch Bugs? Wir haben eine Menge Code ohne Tests: Wo fangen wir an? Wir arbeiten mit mehreren Sprachen: Ist Unit Testing da praktikabel? Was ist, wenn wir eine Kombination aus Softund Hardware entwickeln? Wie können wir wissen, dass wir keine Bugs in unseren Tests haben? Mein Debugger zeigt mir, dass mein Code funktioniert: Wozu brauche ich Tests? Müssen wir Code im TDD-Stil schreiben? Zusammenfassung Der Umgang mit Legacy Code Wo soll man mit dem Einbauen der Tests beginnen? Bestimmen Sie eine Auswahlstrategie Vor- und Nachteile der Strategie»Einfaches zuerst« Vor- und Nachteile der Strategie»Schwieriges zuerst«

9 book Seite 11 Donnerstag, 4. November : Schreiben Sie Integration Tests, bevor Sie mit dem Refactoring beginnen Wichtige Tools für das Unit Testing von Legacy Code Abhängigkeiten isolieren Sie leicht mit Typemock Isolator Testbarkeitsprobleme finden Sie mit Depender Verwenden Sie JMockit für Java-Legacy-Code Verwenden Sie Vise beim Refactoring Ihres Java-Codes Verwenden Sie FitNesse für Akzeptanztests, bevor Sie mit dem Refactoring beginnen Lesen Sie das Buch von Michael Feathers zu Legacy Code Verwenden Sie NDepend, um Ihren Produktionscode zu untersuchen Verwenden Sie ReSharper für die Navigation und das Refactoring des Produktionscodes Spüren Sie Code-Duplikate (und Bugs) mit Simian auf Spüren Sie Threading-Probleme mit Typemock Racer auf Zusammenfassung A Design und Testbarkeit A.1 Warum sollte ich mir Gedanken um die Testbarkeit in meinem Design machen? A.2 Designziele für die Testbarkeit A.2.1 Deklarieren Sie Methoden standardmäßig als virtuell A.2.2 Benutzen Sie ein Interface-basiertes Design A.2.3 Deklarieren Sie Klassen standardmäßig als nicht versiegelt A.2.4 Vermeiden Sie es, konkrete Klassen innerhalb von Methoden mit Logik zu instanziieren A.2.5 Vermeiden Sie direkte Aufrufe von statischen Methoden A.2.6 Vermeiden Sie Konstruktoren und statische Konstruktoren, die Logik enthalten A.2.7 Trennen Sie die Singleton-Logik und Singleton-Halter A.3 Vor- und Nachteile des Designs zum Zwecke der Testbarkeit A.3.1 Arbeitsumfang A.3.2 Komplexität

10 book Seite 12 Donnerstag, 4. November :02 18 A.3.3 Das Preisgeben von sensiblem IP A.3.4 Manchmal geht s nicht A.4 Alternativen des Designs zum Zwecke der Testbarkeit A.5 Zusammenfassung B Tools und Frameworks B.1 Isolation Frameworks B.1.1 Moq B.1.2 Rhino Mocks B.1.3 Typemock Isolator B.1.4 NMock B.1.5 NUnit.Mocks B.2 Test Frameworks B.2.1 Microsofts Unit Testing Framework B.2.2 NUnit B.2.3 MbUnit B.2.4 Gallio B.2.5 xunit B.2.6 Pex B.3 Dependency Injection und IoC-Container B.3.1 StructureMap B.3.2 Microsoft Unity B.3.3 Castle Windsor B.3.4 Autofac B.3.5 Common Service Locator Library B.3.6 Spring.NET B.3.7 Microsoft Managed Extensibility Framework B.3.8 Ninject B.4 Datenbanktests B.4.1 Verwenden Sie Integration Tests für Ihre Datenschicht B.4.2 Verwenden Sie Rollback-Attribute B.4.3 Verwenden Sie TransactionScope für ein Rollback B.5 Webtests B.5.1 Ivonna B.5.2 Team System Web Test B.5.3 NUnitAsp B.5.4 Watir

11 book Seite 13 Donnerstag, 4. November :02 18 B.5.5 WatiN B.5.6 Selenium B.6 UI-Tests B.6.1 NUnitForms B.6.2 Project White B.6.3 Visual Studio UI Test B.7 Thread-bezogene Tests B.7.1 Typemock Racer B.7.2 Microsoft CHESS B.7.3 Osherove.ThreadTester B.8 Akzeptanztests B.8.1 FitNesse B.8.2 StoryTeller C Leitfaden Test-Review Stichwortverzeichnis