Stefan Lieser Web:

Begriffsklärung Unit Test, Integration Test, etc. Überblick MSTest Code Coverage Analyse Red, Green, Refactor Vorgehensweise bei TDD Isolieren von Abhängigkeiten zu Fuß Mock Frameworks (Rhino.Mocks, TypeMock) Links, Literatur

Unit Test Automatisiert mit Hilfe eines Test Frameworks (MSTest, NUnit, MbUnit, etc.). Testet die kleinste Einheit, in der Regel eine Klasse. Die class under test wird von ihren Abhängigkeiten isoliert. Integration Test Tests über mehrere Layer z.B. auch inkl. Datenbankzugriff

using Microsoft.VisualStudio.TestTools.UnitTesting; namespace MeineTests { [TestClass] public class BasicTests { [TestMethod] public void Test() { int i = 5; Assert.AreEqual(5, i); } Klasse enthält Tests Diese Methode ist ein Test Annahme die erfüllt sein muss

[TestClass] public class BasicTests { private IList list; [TestInitialize] public void Setup() { list = new List (); } [TestMethod] public void Test() { list.Add("bla"); Assert.AreEqual(1, list.Count); } Initialisierung die vor jeder Testmethode ausgeführt wird.

[TestClass] public class BasicTests { [TestMethod] public void Test() { // … } [TestCleanup] public void Teardown() { MockManager.Verify(); } Teardown/Cleanup das nach jedem Test ausgeführt wird

DEMO BasicTests BacklogTests

Im Fenster Test Results: Rechte Maustaste, Add/Remove Columns… Class Name ergänzen Spalten wie folgt anordnen Project Class Name Test Name

Damit MSTest ein Projekt als Testprojekt erkennt muss in der Projektdatei folgender Eintrag vorhanden sein: {3AC096D0-A1C2-E12C-1390-A FDAB}; {FAE04EC0-301F-11D3-BF4B-00C04F79EFBC} Solange man Testprojekte über das vorhandene Projekt-Template anlegt ist dies gegeben...

Die Code Coverage Analyse dient dazu Quellcode zu finden der während der Tests nicht ausgeführt wird. 100% Code Coverage heißt nicht 100% Test Coverage!!!

100% Code Coverage wird bereits bei einem beliebigen i mit 0 < i < 10 erreicht. 100% Test Coverage ist erst bei allen i mit 0 < i < 10 erreicht. Strategie: jeweils die Randfälle und einige normale Fälle testen hier z.B. -1, 0, 1, 9, 10, 11, 5 if ((i > 0) && (i < 10)) { Berechne(i); }

Die Testrun Configuration legt fest welche Assemblies instrumentiert werden. Test | Edit Test Run Configurations... | Code Coverage Anschließend die Tests neu ausführen. Im Fenster Code Coverage Results kann die Einfärbung des Quellcodes aktiviert werden.

DEMO BacklogItemTests

Red Schreibe einen Test. Implementiere gerade soviel dass es syntaktisch korrekt ist. Test schlägt fehl. Green Ergänze die Implementierung gerade so weit, dass der Test erfolgreich ist. Refactor Überarbeite die Implementierung so dass sie besser wird, ohne ihr äußeres Verhalten zu modifizieren.

Sapir-Whorf Hypothese Die Sprache formt das Denken. Spezifikation (statt Test) trifft die Sache eher. Test first führt dazu dass man eine neue Funktionalität erst anwendet ehe man sie implementiert. Dadurch wird die API in der Regel besser.

Die Testabdeckung (Coverage) ist in der Regel höher als bei Tests die im Nachhinein ergänzt werden. Kein Dogma! Manchmal geht es nur im Nachhinein. Manchmal hilfreich: erst einen Spike ohne Tests, diesen dann wegwerfen und Test first neu beginnen.

DEMO BacklogItemTests

Zustandsorientiert (state based tests) Assert.AreEqual(5, i); Verhaltensorientiert (interaction based tests) Expect.Call( Service.Send).Repeat.Once;

Unit Tests testen eine Klasse isoliert, also ohne ihre Abhängigkeiten. Die Abhängigkeiten werden durch Test Doubles ersetzt. Tipp: Software Principles beherzigen SRP Single Responsibility Principle OCP Open Close Principle LSP Liskov Substitution Principle DIP Dependency Inversion Principle ISP Interface Segregation Principle

Implementieren der Test Doubles durch handgeschriebene Klassen, von einem Mock Framework generierte Klassen.

public interface IRepository { Customer CustomerById(int id); } public class FakeRepository : IRepository { public delegate Customer CustomerByIdDelegate(int id); public CustomerByIdDelegate CustomerByIdMethod = delegate { return null; }; public Customer CustomerById(int id) { return CustomerByIdMethod(id); }

Stub Ein Double welches die Abhängigkeit der zu testenden Klasse ausfüllt. Rückgabewerte und Verhalten können von außen gesteuert werden um das Verhalten der zu testenden Klasse zu beeinflussen. Mock Es werden Erwartungen definiert die durch den Test erfüllt werden müssen. Wird eine Erwartung nicht erfüllt schlägt der Test fehl.

Record/Replay Während der Record Phase wird definiert wie sich das Objekt später verhalten soll. In der Replay Phase wird das zuvor aufgezeichnete Verhalten abgespielt. Bei Mock Objects zusätzlich: Nach der Replay Phase wird geprüft, ob alle erwarteten Aufrufe korrekt erfolgt sind.

Rhino.Mocks (open source) Implementiert mit Hilfe von zur Laufzeit generierten Proxy Klassen. Verwendet Castle Proxy TypeMock (commercial, abgespeckt free) Verwendet das Profiler API um Aufrufe abzufangen. Technisch leistungsfähiger (z.B. Unterstützung für statische Methoden).

DEMO

Legacy Code = Code ohne Tests ISBN-10:

Business Domain Objects stehen im Vordergrund ISBN:

5 Software Principles SRP Single Responsibility OCP Open Close LSP Liskov Substitution DIP Dependency Inversion ISP Interface Segregation ISBN:

Rhino.Mocks TypeMock NUnit JetBrains ReSharper