Test Driven Development

by Roland Beenhakker 4. May 2009 17:00

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:

  1. Door het schrijven van een test wordt tegelijk de specificaties vastgelegd. Immers een test wordt gemaakt aan de hand van een specificatie.
  2. Wie de uiteindelijke functie ook schrijft, zolang de test faalt voldoet hij niet aan de specificaties.
  3. 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)
  4. 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

Delphi Prism

by Roland Beenhakker 18. December 2008 11:33

We hebben Delphi Prism toegevoegd aan ons arsenaal .NET ontwikkeltools. Delphi Prism is feitelijk de opvolger van Delphi for .NET.
Grote verschil met Delphi for .NET is dat Delphi Prism geen eigen IDE meer heeft, maar wordt aangeboden als een Microsoft Visual Studio Plugin. Dit heeft voor CodeGear als voordeel dat ze nu makkelijker bij kunnen blijven op het gebied van .NET omdat in Visual Studio bijvoorbeeld alle designers voor de diverse .NET technologieën reeds aanwezig zijn. Om die reden liep Delphi for .NET vaak een .NET versie achter.

Als programmeertaal doet Delphi Prism niet onder voor C# en VB.NET, sterker nog Delphi Prism biedt een aantal mogelijkheden die in C# en VB.NET (nog) niet kunnen. Met Delphi Prism heeft CodeGear Delphi nu als volwaardige alternatieve taal naast C# en VB.NET gezet.
De grote vraag is echter wanneer kiezen voor Delphi Prism i.p.v. C#? Beensoft heeft al haar .NET opdrachten sinds 2005 gestandardiseerd op C# en dat zal niet veranderen.
Delphi Prism zullen we met name gebruiken voor Delphi applicaties, die op welke manier dan ook, gecombineerd worden met .NET technologie. Denk bijvoorbeeld aan een applicatie die naast een Delphi Backoffice gebruikt maakt van een ASP.NET website. Delphi Prism biedt dan de mogelijkheid om broncodes tussen beide applicaties te delen.

Kortom Delphi Prism is een goede aanvulling op onze toolset!

Powered by BlogEngine.NET 1.4.5.0
Theme by Mads Kristensen

Welkom

Op dit weblog geven professionals binnen Beensoft hun mening over zaken die hen bezig houden en interessant kunnen zijn voor onze klanten en bezoekers. 

Over Beensoft
Beensoft bouwt oplossingen voor het Microsoft platform en mobiele oplossingen voor o.a. Apple iOS (iPhone/iPad) en Google Android

Beensoft, altijd de beste oplossing voor het desktop, web en mobiele platform.  

 

Hamsterkoog 3-L
1822 CD Alkmaar
Website: www.beensoft.nl
E-mail: info [at] beensoft.nl

Disclaimer

Beensoft heeft de inhoud van deze site met de grootst mogelijke zorg samengesteld. Desondanks aanvaardt Beensoft geen enkele aansprakelijkheid voor de inhoud daarvan, noch voor enige schade, van welke aard ook, welke het directe of indirecte gevolg is van handelen en/of nalaten en/of beslissingen die (mede) gebaseerd zijn op de inhoud van deze site.

Blog post zijn geschreven op persoonlijke titel van de auteurs. Een gegeven mening is de mening van de  auteur, en hoeft niet per se overeen te komen met de mening van Beensoft Software Engineering.