Bij Beensoft zijn we constant bezig met het verbeteren van de kwaliteit van onze software. Een nieuwe trend in software land is Test Driven Development, kortweg TDD. Test Driven Development is een ontwikkel methodiek gebaseerd op vooraf geschreven test-cases. TDD is dus geen methode om te testen.
Testen van geschreven software is iets wat traditioneel aan het eind van het ontwikkelproces wordt uitgevoerd. De ontwikkelaar bouwt zijn software volgens de aangeleverde specificaties en een tester (in het meest luxe geval iemand anders) toetst of de software voldoet aan de specificaties, en of deze geen fouten bevat.
Een luxe vorm van testen is 'automatisch' testen. Bij deze manier van testen, Test_automation genoemd, wordem bepaalde stukken code (een unit of code) getest op de juiste werking. Je moet dan denken aan het testen van bepaalde functies en/of procedures.
Test Driven Development stelt dat deze unit tests geschreven moeten worden voordat de daadwerkelijke code uitgewerkt wordt. Dus niet beginnen met het maken van een functie, en dan een test, maar andersom!
Maar dat kost toch meer tijd?
Gevoelsmatig zou je denken dat het schrijven van de testen meer tijd kost, die er meestal niet is. In de praktijk blijkt dat deze manier van aanpak over het algemeen tijd scheelt omdat de kwaliteit en de onderhoudbaarheid van de software beter is kost het veel minder tijd om de software te onderhouden. De onderhoudsfase is de grootste fase in het software ontwikkelproces.
Denk aan de volgende voordelen:
-
Door het schrijven van een test wordt tegelijk de specificaties vastgelegd. Immers een test wordt gemaakt aan de hand van een specificatie.
-
Wie de uiteindelijke functie ook schrijft, zolang de test faalt voldoet hij niet aan de specificaties.
-
Nieuwe specificaties, wijzigingen leiden tot het refactoren van de code. Falende testen geven aan dat dit niet correct is gedaan. (Dit kan 'oude' code zijn)
-
Testen op unit niveau zorgen er voor dat de software meer gelaagd en minder complex wordt (Kleinere functies) , dus beter onderhoudbaar. (Minder tijd)
Testen worden uitgevoerd op basis van beweringen (Asserts) of verwachtingen.
Een voorbeeld:
Stel we schrijven een Rekenmachine applicatie, die zal functies hebben als Optellen, aftrekken, delen etc.
Als we deze applicatie volgens de TDD methodiek maken dan doorlopen we de volgende stappen:
1. Het schrijven van een test voor Optellen
'Als we de functie twee getallen geven 3 en 2 dan moet het resultaat 5 zijn'
In C# code ziet dit er als volgt uit:
[TestMethod]
public void Add()
{
int Int1 = 2;
int Int2 = 3;
int Result = calculator.Add(Int1, Int2);
Assert.AreEqual(5, Result);
}
In dit geval is de Add functie van calculator de daadwerkelijke functie.
2. Het schrijven van een test voor Delen
'Als we deze functie twee getallen geven, 6 en 3 dan moet het resultaat 2 zijn'
'Als het tweede getal 0 is dan verwachten we een DivideByZeroException'
[TestMethod]
public void Divide()
{
int Int1 = 6;
int Int2 = 3;
double Result = calculator.Divide(Int1, Int2);
Assert.AreEqual(2, Result);
}
[TestMethod]
[ExpectedException(typeof(DivideByZeroException))]
public void DivideByZero()
{
int Int1 = 6;
int Int2 = 0;
double Result = calculator.Divide(Int1, Int2);
}
3. Doe een test run
Aangezien we functies nog niet uitgewerkt hebben falen alle drie te testen.
4. Schrijf de daadwerkelijke code
Deze eenvoudige functies worden als volgt uitgewerkt:
public int Add(int Int1, int Int2)
{
return Int1 + Int2;
}
public double Divide(int Int1, int Int2)
{
return Int1 / Int2;
}
Merkop dat de ontwikkelaar voor de Divide functie de parameters, met de slechte naamgeving Int1 en Int2, makkelijk verkeerd zou kunnen delen (Int2/Int1 ipv Int1/Int2). De test zal dan echter falen omdat dan niet het verwachte resultaat zal terugkomen. (0,5 ipv 2)
Conclusie
Test Drive Development draagt significant bij aan de kwaliteit van code. Naast het feit dat het automatisch testen fouten in een vroeg stadium onderkent bakt het feitelijk de specificaties in de software. In Microsoft Visual Studio 2008 is het testen volledig geïntegreerd.
Meer informatie in de blogpost op ons .NET Power Unleashed weblog (Engelstalig): Exploring Test Driven Development