Test Driven Development “Onze passie is het helpen van organisaties bij het professionaliseren en optimaliseren van hun software development” Test Driven Development
Wie is wie? Menno Jongerius CTO & Project Lead Developer Johan Smarius Arjen Kraak Project Lead Developer
We vertrouwen in principe alle code NIET We vertrouwen in principe alle code NIET. Om vertrouwen te krijgen richten we testen in. Testen bestaan in verschillende vormen en maten. Vandaag hebben we het over vooral unit testen. Andere soorten testen (keten, integratie) krijgen vandaag weinig tot geen aandacht. Weet dat daarvoor andere tooling voor beschikbaar is.
Bij een constante ontwikkelsnelheid (toename codebase) neemt de testbare codebase ook toe. Hierdoor neemt ook de testbelasting toe. Wat we eigenlijk willen is dat de test belasting gelijk blijft. Dit kunnen we bereiken door een architectuur in te richten waarbij afhankelijkheden worden geminimaliseerd en componenten klein en geïsoleerd zijn. Op deze manier worden de gevolgen van aanpassingen voorspelbaar en kan met nagenoeg dezelfde inspanning (regressie + functionele testen)de codebase worden uitgebreid. Kortom je kan dit bereiken door: - automatisch testen - juiste (losely coupled) architectuur Voorwaarde is wel dat requirements op dusdanige manier zijn geformuleerd dat de acceptatie criteria testbaar zijn. Het onderwerp van vandaag concentreert zich op de architectuur aspecten.
Waarom automatisch testen? Veranderingen leveren voorspelbaar gedrag en dus vertrouwen De testen zijn documentatie van specificaties Opsporen van bugs is eenvoudig door het hebben van kleine en geïsoleerde eenheden(classes, functies) Het helpt je om SOLID na te denken over de architectuur
Uncle Bob over TDD (Robert C. Martin) “The act of writing a unit test is more an act of design than of verification. It is also more an act of documentation than of verification. The act of writing a unit test closes a remarkable number of feedback loops, the least of which is the one pertaining to verification of function”
Kent Beck over TDD “TDD encourages simple designs and inspires confidence”
F ast I solated R epeatable S elf-verifying T imely Een goede unit test F ast I solated R epeatable S elf-verifying T imely De optimale unit test moet aan de volgende voorwaarden voldoen: Snel, Geisoleerd, Herhaalbaar,Zonder menselijk ingrijpen een resultaat, Automatisch tijdens coderen
TDD workflow Je begint met het schrijven van de unit test. Deze compileert (als het goed is niet). Vervolgens zorg je ervoor dat met minimale code de solution compileert en de unit test faalt. De laatste stap zorgt ervoor dat net voldoende code wordt aangebracht om de test te doen slagen. Gedurende de levenscyclus van het programmeren herhaalt zich dit continue.Het proces houdt niet op nadat het groen resultaat is behaald. Groen <> DONE !!!!
Testen helpt je na te denken over gedrag De succes criteria zullen 1 of meerdere unit testen moeten opleveren. Startend vanuit de unit testen kan de code volgens de functionele requirements worden geïmplementeerd. In dit voorbeeld heb je bijvoorbeeld een Transaction object waarbinnen de business rules worden gevalideerd. Elke rule zou in een aparte functie of zelfs klasse kunnen worden geïmplementeerd en dus ook geïsoleerd kunnen worden getest met de verwachte goed/fout resultaten met verschillende input.
Je ziet veel teams de applicatie opdelen in lagen Je ziet veel teams de applicatie opdelen in lagen. Een klassiek voorbeeld is de 3 lagen structuur aan de linkerkant. Uiteindelijk wordt de oplossing nog groot. Soms is het zelfs zo dat een laag een applicatie op zich wordt. Wat je eigenlijk wilt is dat de applicatie een verzameling van bouwstenen die worden gebundeld in (micro) services die in losse projecten of zelfs solutions worden gerealiseerd. Het uiteindelijke doel is om orde in de chaos te creëren door kleine eenheden te maken die eenvoudig te begrijpen zijn.
Test Driven Development ervaringen Ronny Kennes (Testdorp)
Test driven development praktijkcase Test-first en refactor opties Mocking met nSubstitute Inversion of control Mocking van je datalaag ServiceLocator
Inversion of Control in de praktijk Dependency Injection Aanmaken objecten uitbesteedt aan IoC container IoC Container http://www.palmmedia.de/blog/2011/8/30/ioc-container-benchmark-performance-comparison
Keuze IoC Container Functionaliteit Performance Volwassenheid Actieve ondersteuning Persoonlijke/team voorkeur