1 / 17

TDD mit MSTest

TDD mit MSTest. Stefan Lieser Email: stefan@lieser-online.de Web: http://www.lieser-online.de. Agenda. Begriffsklärung Unit Test, Integration Test, etc. Überblick MSTest Red , Green, Refactor Vorgehensweise bei TDD Mock Frameworks Rhino.Mocks TypeMock

abrial
Download Presentation

TDD mit MSTest

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TDD mit MSTest Stefan Lieser Email: stefan@lieser-online.de Web: http://www.lieser-online.de

  2. Agenda • Begriffsklärung • Unit Test, Integration Test, etc. • Überblick MSTest • Red, Green, Refactor • Vorgehensweise bei TDD • Mock Frameworks • Rhino.Mocks • TypeMock • Sollen Tests das Design beeinflussen?

  3. Begriffsklärung • Unit Test • Automatisiert durch Anwendung eines Test Frameworks (MSTest, Nunit, MbUnit, etc.). • Testet die kleinste Einheit, in der Regel eine Klasse. • Die „classundertest“ ist von ihren Abhängigkeiten isoliert. • Integration Test • Tests über mehrere Layer • z.B. auch inkl. Datenbankzugriff

  4. Überblick MSTest usingMicrosoft.VisualStudio.TestTools.UnitTesting; namespaceMeineTests { [TestClass] publicclassBasicTests { [TestMethod] publicvoid Test() { int i = 5; Assert.AreEqual(5, i); } } } Klasse enthält Tests Diese Methode ist ein Test Annahme die erfüllt sein muss

  5. Test Setup [TestClass] publicclassBasicTests { private IList<string> list; [TestInitialize] publicvoid Setup() { list = new List<string>(); } [TestMethod] publicvoid Test() { list.Add("bla"); Assert.AreEqual(1, list.Count); } } Initialisierung die vor jeder Testmethode ausgeführt wird.

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

  7. Code Coverage Analyse • Die Code Coverage Analyse dient dazu Quellcode zu finden der während der Tests nicht ausgeführt wird. • 100% Code Coverageheißt nicht 100% Test Coverage!!! • Beispiel: 100% Code Coverage wird bereits bei einem beliebigen i mit 0 < i < 10 erreicht. 100% Test Coverage erst bei allen i mit 0 < i < 10. if ((i > 0) && (i < 10)) { Berechne(i); }

  8. Code Coverage Analyse - Howto • Die TestrunConfiguration legt fest welche Assemblies instrumentiert werden. • Test | Edit Test Run Configurations... | Code Coverage • Anschließend die Tests neu ausführen. • Im Fenster Code CoverageResults kann die Einfärbung des Quellcodes aktiviert werden.

  9. Red, Green, Refactor • 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 Verhalten zu modifizieren.

  10. Test first? • 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.

  11. Test first? • 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.

  12. Isolieren einer Klasse • Unit Tests testen eine Klasse isoliert, also ohne ihre Abhängigkeiten. • Die Abhängigkeiten werden durch Test Doubles ersetzt. • Implementieren der Test Doubles durch • handgeschriebene Klassen, • von einem Mock Framework generierte Klassen. • Stub • Reines Double • Mock • Stub mit zu prüfenden Erwartungen

  13. Testverfahren • Zustandsorientiert (statebasedtests) • Verhaltensorientiert (interactionbasedtests)

  14. Test Doubles • 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.

  15. Mock Framework - Arbeitsweise • 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.

  16. Mock Frameworks - Beispiele • 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).

  17. Links • Sapir-Whorf These: http://de.wikipedia.org/wiki/Sapir-Whorf-Hypothese • Rhino.Mocks • TypeMock • JetBrains ReSharper • NUnit

More Related