UID:
kobvindex_ERBEBC6947550
Format:
1 online resource (312 pages)
Edition:
2
ISBN:
9783826687211
Note:
Cover -- Titel -- Impressum -- Inhaltsverzeichnis -- Vorwort zur zweiten Auflage -- Vorwort zur ersten Auflage -- Einleitung -- Kapitel 1: Die Grundlagen des Unit Testings -- 1.1 Unit Testing - Schritt für Schritt definiert -- 1.1.1 Die Bedeutung guter Unit Tests -- 1.1.2 Wir alle haben schon Unit Tests geschrieben (irgendwie) -- 1.2 Eigenschaften eines »guten« Unit Tests -- 1.3 Integrationstests -- 1.3.1 Nachteile von nicht automatisierten Integrationstests im Vergleich zu automatisierten Unit Tests -- 1.4 Was Unit Tests »gut« macht -- 1.5 Ein einfaches Unit-Test-Beispiel -- 1.6 Testgetriebene Entwicklung -- 1.7 Die drei Schlüsselqualifikationen für erfolgreiches TDD -- 1.8 Zusammenfassung -- Kapitel 2: Ein erster Unit Test -- 2.1 Frameworks für das Unit Testing -- 2.1.1 Was Unit-Testing-Frameworks bieten -- 2.1.2 Die xUnit-Frameworks -- 2.2 Das LogAn-Projekt wird vorgestellt -- 2.3 Die ersten Schritte mit NUnit -- 2.3.1 Die Installation von NUnit -- 2.3.2 Das Laden der Projektmappe -- 2.3.3 Die Verwendung der NUnit-Attribute in Ihrem Code -- 2.4 Sie schreiben Ihren ersten Test -- 2.4.1 Die Klasse Assert -- 2.4.2 Sie führen Ihren ersten Test mit NUnit aus -- 2.4.3 Sie fügen positive Tests hinzu -- 2.4.4 Von Rot nach Grün: das erfolgreiche Ausführen der Tests -- 2.4.5 Test-Code-Gestaltung -- 2.5 Refactoring zu parametrisierten Tests -- 2.6 Weitere NUnit-Attribute -- 2.6.1 Aufbau und Abbau -- 2.6.2 Auf erwartete Ausnahmen prüfen -- 2.6.3 Das Ignorieren von Tests -- 2.6.4 Die fließende Syntax von NUnit -- 2.6.5 Das Festlegen der Testkategorien -- 2.7 Das Testen auf Zustandsänderungen des Systems statt auf Rückgabewerte -- 2.8 Zusammenfassung -- Kapitel 3: Die Verwendung von Stubs, um Abhängigkeiten aufzulösen -- 3.1 Die Stubs werden vorgestellt -- 3.2 Die Identifizierung einer Dateisystemabhängigkeit in LogAn
,
3.3 Die Entscheidung, wie LogAnalyzer am einfachsten getestet werden kann -- 3.4 Design-Refactoring zur Verbesserung der Testbarkeit -- 3.4.1 Extrahiere ein Interface, um die dahinter liegende Implementierung durch eine andere ersetzen zu können -- 3.4.2 Dependency Injection: Injiziere eine Fake-Implementierung in die zu testende Unit -- 3.4.3 Injiziere einen Fake auf Konstruktor-Ebene (Construktor Injection) -- 3.4.4 Simuliere Ausnahmen über Fakes -- 3.4.5 Injiziere ein Fake als Property Get oder Set -- 3.4.6 Injiziere einen Fake unmittelbar vor einem Methodenaufruf -- 3.5 Variationen der Refactoring-Technik -- 3.5.1 Die Verwendung von Extract and Override, um Fake-Resultate zu erzeugen -- 3.6 Die Überwindung des Kapselungsproblems -- 3.6.1 Die Verwendung von internal und [InternalsVisibleTo] -- 3.6.2 Die Verwendung des Attributs [Conditional] -- 3.6.3 Die Verwendung von #if und #endif zur bedingten Kompilierung -- 3.7 Zusammenfassung -- Kapitel 4: Interaction Testing mit Mock-Objekten -- 4.1 Wertbasiertes Testen versus zustandsbasiertes Testen versus Testen versus Interaction Testing -- 4.2 Der Unterschied zwischen Mocks und Stubs -- 4.3 Ein einfaches manuelles Mock-Beispiel -- 4.4 Die gemeinsame Verwendung von Mock und Stub -- 4.5 Ein Mock pro Test -- 4.6 Fake-Ketten: Stubs, die Mocks oder andere Stubs erzeugen -- 4.7 Die Probleme mit handgeschriebenen Mocks und Stubs -- 4.8 Zusammenfassung -- Kapitel 5: Isolation-(Mock-Objekt-)Frameworks -- 5.1 Warum überhaupt Isolation-Frameworks? -- 5.2 Das dynamische Erzeugen eines Fake-Objekts -- 5.2.1 Die Einführung von NSubstitute in Ihre Tests -- 5.2.2 Das Ersetzen eines handgeschriebenen Fake-Objekts durch ein dynamisches -- 5.3 Die Simulation von Fake-Werten -- 5.3.1 Ein Mock, ein Stub und ein Ausflug in einen Test -- 5.4 Das Testen auf ereignisbezogene Aktivitäten
,
5.4.1 Das Testen eines Event Listeners -- 5.4.2 Der Test, ob ein Event getriggert wurde -- 5.5 Die aktuellen Isolation-Frameworks für .NET -- 5.6 Die Vorteile und Fallstricke von Isolation-Frameworks -- 5.6.1 Fallstricke, die man bei der Verwendung von Isolation-Frameworks besser vermeidet -- 5.6.2 Unlesbarer Testcode -- 5.6.3 Die Verifizierung der falschen Dinge -- 5.6.4 Die Verwendung von mehr als einem Mock pro Test -- 5.6.5 Die Überspezifizierung von Tests -- 5.7 Zusammenfassung -- Kapitel 6: Wir tauchen tiefer ein in die Isolation-Frameworks -- 6.1 Eingeschränkte und uneingeschränkte Frameworks -- 6.1.1 Eingeschränkte Frameworks -- 6.1.2 Uneingeschränkte Frameworks -- 6.1.3 Wie Profiler-basierte uneingeschränkte Frameworks arbeiten -- 6.2 Werte guter Isolation-Frameworks -- 6.3 Eigenschaften, die Zukunftssicherheit und Benutzerfreundlichkeit unterstützen -- 6.3.1 Rekursive Fakes -- 6.3.2 Ignoriere Argumente als Voreinstellung -- 6.3.3 Umfangreiches Fälschen -- 6.3.4 Nicht striktes Verhalten von Fakes -- 6.3.5 Nicht strikte Mocks -- 6.4 Isolation-Framework-Design-Antimuster -- 6.4.1 Konzept-Konfusion -- 6.4.2 Aufnahme und Wiedergabe -- 6.4.3 Klebriges Verhalten -- 6.4.4 Komplexe Syntax -- 6.5 Zusammenfassung -- Kapitel 7: Testhierarchie und Organisation -- 7.1 Automatisierte Builds, die automatisierte Tests laufen lassen -- 7.1.1 Die Anatomie eines Build-Skripts -- 7.1.2 Das Anstoßen von Builds und Integration -- 7.2 Testentwürfe, die auf Geschwindigkeit und Typ basieren -- 7.2.1 Der menschliche Faktor beim Trennen von Unit und Integrationstests -- 7.2.2 Die sichere grüne Zone -- 7.3 Stellen Sie sicher, dass die Tests zu Ihrer Quellcodekontrolle gehören -- 7.4 Das Abbilden der Testklassen auf den zu testenden Code -- 7.4.1 Das Abbilden von Tests auf Projekte -- 7.4.2 Das Abbilden von Tests auf Klassen
,
7.4.3 Das Abbilden von Tests auf bestimmte Methoden -- 7.5 Querschnittsbelang-Injektion -- 7.6 Der Bau einer Test-API für Ihre Applikation -- 7.6.1 Die Verwendung von Testklassen-Vererbungsmustern -- 7.6.2 Der Entwurf von Test-Hilfsklassen und -Hilfsmethoden -- 7.6.3 Machen Sie Ihre API den Entwicklern bekannt -- 7.7 Zusammenfassung -- Kapitel 8: Die Säulen guter Unit Tests -- 8.1 Das Schreiben vertrauenswürdiger Tests -- 8.1.1 Die Entscheidung, wann Tests entfernt oder geändert werden -- 8.1.2 Vermeiden Sie Logik in Tests -- 8.1.3 Testen Sie nur einen Belang -- 8.1.4 Trennen Sie Unit Tests von Integrationstests -- 8.1.5 Stellen Sie Code-Reviews mit Codeabdeckung sicher -- 8.2 Das Schreiben wartbarer Tests -- 8.2.1 Das Testen privater oder geschützter Methoden -- 8.2.2 Das Entfernen von Duplizitäten -- 8.2.3 Die Verwendung von Setup-Methoden in einer wartbaren Art und Weise -- 8.2.4 Das Erzwingen der Test-Isolierung -- 8.2.5 Vermeiden Sie mehrfache Asserts für unterschiedliche Belange -- 8.2.6 Der Vergleich von Objekten -- 8.2.7 Vermeiden Sie eine Überspezifizierung der Tests -- 8.3 Das Schreiben lesbarer Tests -- 8.3.1 Die Benennung der Unit Tests -- 8.3.2 Die Benennung der Variablen -- 8.3.3 Benachrichtigen Sie sinnvoll -- 8.3.4 Das Trennen der Asserts von den Aktionen -- 8.3.5 Aufbauen und Abreißen -- 8.4 Zusammenfassung -- Kapitel 9: Die Integration von Unit Tests in die Organisation -- 9.1 Schritte, um ein Agent des Wandels zu werden -- 9.1.1 Seien Sie auf die schweren Fragen vorbereitet -- 9.1.2 Überzeugen Sie Insider: Champions und Blockierer -- 9.1.3 Identifizieren Sie mögliche Einstiegspunkte -- 9.2 Wege zum Erfolg -- 9.2.1 Guerilla-Implementierung (Bottom-up) -- 9.2.2 Überzeugen Sie das Management (Top-down) -- 9.2.3 Holen Sie einen externen Champion -- 9.2.4 Machen Sie Fortschritte sichtbar -- 9.2.5 Streben Sie bestimmte Ziele an
,
9.2.6 Machen Sie sich klar, dass es Hürden geben wird -- 9.3 Wege zum Misserfolg -- 9.3.1 Mangelnde Triebkraft -- 9.3.2 Mangelnde politische Unterstützung -- 9.3.3 Schlechte Implementierungen und erste Eindrücke -- 9.3.4 Mangelnde Teamunterstützung -- 9.4 Einflussfaktoren -- 9.5 Schwierige Fragen und Antworten -- 9.5.1 Wie viel zusätzliche Zeit wird der aktuelle Prozess für das Unit Testing benötigen? -- 9.5.2 Ist mein Job bei der QS in Gefahr wegen des Unit Testing? -- 9.5.3 Woher wissen wir, dass Unit Tests wirklich funktionieren? -- 9.5.4 Gibt es denn einen Beweis, dass Unit Testing hilft? -- 9.5.5 Warum findet die QS immer noch Bugs? -- 9.5.6 Wir haben eine Menge Code ohne Tests: Wo fangen wir an? -- 9.5.7 Wir arbeiten mit mehreren Sprachen: Ist Unit Testing da praktikabel? -- 9.5.8 Was ist, wenn wir eine Kombination aus Soft- und Hardware entwickeln? -- 9.5.9 Wie können wir wissen, dass wir keine Bugs in unseren Tests haben? -- 9.5.10 Mein Debugger zeigt mir, dass mein Code funktioniert: Wozu brauche ich Tests? -- 9.5.11 Müssen wir Code im TDD-Stil schreiben? -- 9.6 Zusammenfassung -- Kapitel 10: Der Umgang mit Legacy-Code -- 10.1 Wo soll man mit dem Einbauen der Tests beginnen? -- 10.2 Bestimmen Sie eine Auswahlstrategie -- 10.2.1 Vor- und Nachteile der Strategie »Einfaches zuerst« -- 10.2.2 Vor- und Nachteile der Strategie »Schwieriges zuerst« -- 10.3 Schreiben Sie Integrationstests, bevor Sie mit dem Refactoring beginnen -- 10.4 Wichtige Tools für das Unit Testing von Legacy-Code -- 10.4.1 Abhängigkeiten isolieren Sie leicht mit uneingeschränkten Isolation-Frameworks -- 10.4.2 Verwenden Sie JMockit für Java-Legacy-Code -- 10.4.3 Verwenden Sie Vise beim Refactoring Ihres Java-Codes -- 10.4.4 Verwenden Sie Akzeptanztests, bevor Sie mit dem Refactoring beginnen -- 10.4.5 Lesen Sie das Buch von Michael Feathers zu Legacy-Code
,
10.4.6 Verwenden Sie NDepend, um Ihren Produktionscode zu untersuchen
Additional Edition:
Print version: Osherove, Roy The Art of Unit Testing Frechen : mitp,c2015
Keywords:
Electronic books.
URL:
https://ebookcentral.proquest.com/lib/th-brandenburg/detail.action?docID=6947550
Bookmarklink
