De precieze code die Visual Studio genereert zal variëren op grond van de methode die getest wordt. Voor methoden die niet publiek zijn, wordt bijvoorbeeld met behulp van reflection een reeks instructies samengesteld om ook deze te kunnen testen.

Stap 2: De testen (her)schrijven

We zien een tweetal attributen terugkomen in de klasse waar de testmethoden worden geplaatst. Een methode die in de test moet worden uitgevoerd wordt aangeduid met de TestMethod()-attribuut. De klasse zelf krijgt het attribuut TestClass(). Beide attributen zijn terug te vinden in de Microsoft.VisualStudio.QualityTools.UnitTesting.Framework-namespace. Wanneer de testrun plaatsvindt kan met behulp van reflection gekeken worden welke klassen de testmethoden bevat en welke methoden getest moeten worden. Een essentieel aspect van de test is dat enkel methoden worden getest die geen parameters bevatten. De compiler controleert dit overigens niet.

De testmethode ConstructorTest() creëert een Task-object en meldt dan dat de test geen uitsluitsel geeft. Hiermee wordt gemeld dat de test niet mislukt is, of geslaagd, maar dat dit eenvoudigweg niet vastgesteld kan worden. Hiervoor wordt de instructie Assert.Inconclusive gebruikt. Om de test wat meer zin te geven, kunnen we de test uitbreiden zoals hieronder:

_
  Public Sub ConstructorTest()
    Dim name As String = "Nieuwe taak"
    Dim myTask As Task = New Task(name)
    Assert.AreEqual(name, myTask.Name,_
      "Task object niet goed geïnitialiseerd.")
  End Sub

Je ziet dat de controle plaatsvindt met behulp van de Assert.AreEqual()-methode. De Assert-klasse heeft ook een AreEqual()-methode met objecten als parameters en dus zonder generics. De generics-versie heeft echter vaak de voorkeur. Op deze manier wordt namelijk tijdens compilatie al geverifieerd dat de types overeenkomen. Dat scheelt weer enkele veel voorkomende fouten in de test.

De generics-versie heeft echter vaak de voorkeur. Op deze manier wordt namelijk tijdens compilatie al geverifieerd dat de types overeenkomen

We hebben nu alleen nog niet de eigenschap Name opgenomen in de Task-klasse, dus we moeten deze toevoegen. Als we dat niet doen, zou het project niet eens compileren. We hebben nu nog geen implementatie ingevoerd, maar laten we toch eens een test uitvoeren.

Stap 3: Testen uitvoeren

Om alle testen in het project te testen hoeven we enkel het testproject uit te voeren. In Visual Studio selecteer je hiervoor het project TaskOrganizerTest in de solution explorer. In het context-menu kies je Set as StartUp Project. Via F5 of Ctrl-F5 (of Debug > Start Debugging respectievelijk Debug > Start Without Debugging) kun je de testen uitvoeren.

Fig. 4: Het testresultaat na het uitvoeren van de test

In het Test Results-scherm verschijnt een lijst met alle testen in het project. Nu hebben we nog maar één test in het project zitten, dus verschijnt er ook één test met het bijbehorende resultaat. Zodra de uitvoering gestart is, zullen de testen de status pending hebben. Het resultaat van de test is natuurlijk Failed (zie figuur 4). Door op de kolommen in het scherm te klikken kan extra informatie getoond worden. Je kunt ook meer details te weten komen door te dubbelklikken op een regel in het scherm. Via het context-menu kan je per regel direct naar de betreffende programmacode van de test springen.

Nu weten we natuurlijk wat er misgaat in deze test. Je hoeft enkel maar de waarde van de Name-eigenschap opgeven in de constructor aan de hand van de opgegeven parameter. Voeg deze initialisatie toe en voer de test nog eens uit om te controleren dat het nu wel goed gaat.

We hebben nu een begin gemaakt en het project voorzien van unit testen. Door eerst een test te schrijven en daarna de implementatie beschikken we op termijn over een flinke set testen die op ieder moment uitgevoerd kunnen worden. Laten we eens kijken wat er nog meer mogelijk is in een unit test.

Controleren op excepties

De volgende stap in de Task-klasse is een controle op de naam van de taak. De Name-eigenschap kunnen we wel rechtstreeks zetten, maar voordat we deze vanuit de constructor in de eigenschap plaatsen, kunnen we controleren of er wel een valide naam aan de taak wordt toegekend. Hiertoe voegen we twee testen toe die controleren of de opgegeven naam niet null of een lege string is. Hieronder staat de relevante programmacode.

_
    "Ten onrechte wordt Nothing geaccepteerd _
    bij instantiatie.")> _
  Public Sub TestGeenNothingAlsNaam()
    Dim myTask As Task = New Task(Nothing)
  End Sub

_
    "Ten onrechte wordt een lege string geaccepteerd _
    bij instantiatie.")> _
  Public Sub TestGeenLegeStringAlsNaam()
    Dim myTask As Task = New Task("")
  End Sub

Het valt direct op dat er geen try-catch blok nodig is die expliciet test op de betreffende exceptie. Daarentegen is een extra attribuut op de methode geplaatst die het type exceptie als parameter meekrijgt.  Bovendien kan, optioneel, een bericht worden opgegeven zodra de betreffende exceptie niet optreedt. Zodra de test wordt uitgevoerd zal deze falen wanneer de methode geen exceptie opwerpt. Als je de test nu uitvoert (via F5, of Ctrl-F5) zul je merken dat we de parameter in de constructor nog niet valideren, en de test zal dus mislukken.

Op grond van deze falende testen moeten we de programmacode aanpassen zodat we de betreffende functionaliteit wel succesvol kunnen testen. We verifiëren dus eerst de parameter voor we deze toekennen aan de Name-eigenschap.

Private m_name As String
Public Property Name() As String
  Get
    Return m_name
  End Get
  Private Set(ByVal value As String)
    If value Is Nothing Then Throw New _
      ArgumentNullException( _
        "Naam kan niet Nothing zijn.")
    If value.Trim.Length = 0 Then Throw New _
      ArgumentException("Naam kan niet leeg zijn.")
    m_name = value
  End Set
End Property

Public Sub New(ByVal taskName As String)
  Name = taskName
End Sub

We maken in de implementatie van de Name-eigenschap ook gebruik van de mogelijkheid om verschillen in toegankelijkheid toe te passen. Door de Set-methode als Private te markeren kan Name wel geraadpleegd worden buiten de klasse, maar niet veranderd.

Zodra deze validatie is toegevoegd kunnen we de test opnieuw uitvoeren en verifiëren dat de implementatie correct is. Alle drie de testen in het project worden uitgevoerd om te controleren dat er door het toevoegen van deze code geen onverwachte fouten optreden. De echte waarde van unit testen komt tot uiting wanneer de programmacode in de loop der tijd verandert. Een complete reeks van testen zorgt er voor dat we geen functionaliteit stuk maken tijdens het onderhoud en verbetering van deze programmacode.

Een complete reeks van testen zorgt er voor dat we geen functionaliteit stuk maken tijdens het onderhoud en verbetering van deze programmacode

Testgegevens uit een database ophalen

We voegen nu de mogelijkheid toe dat een Task-object ook de voortgang kan bijhouden. Dit gebeurt via een methode met een percentage als parameter. We voegen bovendien een controle toe dat de opgegeven waarde niet groter dan 100 kan zijn. Bovendien geldt dat een taak met een voortgangspercentage tussen 0 en 100 niet klaar kan zijn. Is de voortgang 0 dan is de taak niet gestart, en is staat de teller op 100 dan is de taak gereed.

We moeten, om dit netjes volgens de TDD-methode te doen, eerst een test maken voor de controle op de ingevoerde waarde voordat we de methode implementeren. We moeten echter ook een reeks test-waarden creëren tegen welke we de implementatie kunnen verifiëren. In plaats van een individuele test voor iedere test-case of een for-lus kunnen we ook een data-gedreven test maken die de testgegevens uit een database haalt.

We beginnen met het toevoegen van een test met de naam UpdateProgressTest(). Dit is een methode in de TaskTest-klasse met het attribuut TestMethod(). Via Test > Windows > Test View krijgen we deze test ook te zien in een lijst.

Fig. 5: Test View scherm

Het Test View-scherm kun je gebruiken om specifieke tests uit te voeren en specifieke eigenschappen van een test te bekijken. We kunnen ook extra kolommen toevoegen, via de rechtermuisknop op een kolom. Daarmee kunnen we de testen sorteren en bekijken zoals we zelf willen. Sommige eigenschappen in deze kolommen zijn weer terug te vinden in attributen op de testmethode. Wanneer we bijvoorbeeld via de eigenschappen een test-eigenaar (Owner) hebben opgegeven, zien we deze ook als attribuut Owner("Sander")> terug boven de methode. Er is een vrije-veld attribuut TestProperty waarin een naam-waarde-paar voor van alles kan worden opgeslagen.

We kunnen ook kijken naar eigenschappen die niet in kolommen zijn terug te vinden. Kies hiervoor Properties uit het context-menu. Zo kunnen we onder meer een ConnectionString opgeven en een tabelnaam om testgegevens uit op te halen. Het ligt nogal voor de hand dat wanneer we specifieke testwaarden willen opgeven, we een databaseverbinding nodig hebben. Vanuit de Server Explorer kunnen we via Create new SQL Server Database een database toevoegen aan het testproject. Realiseer je dan wel dat wanneer je deze test op een andere computer wil uitvoeren, de database wel toegankelijk moet zijn. Je kunt daarom ook een database-bestand toevoegen via: Project > Add new item > SQL Database. Daarmee volgen de testgegevens het testproject. Als de database groot wordt is dat natuurlijk minder praktisch en kunnen we beter voor een centrale databaselocatie kiezen. Voor nu voegen we een database bestand toe onder de naam TasksTest.mdf.

Kies daarna Tools > Connect to database…. Selecteer in het dialoogvenster de optie Microsoft SQL Server Database File en kies Continue. Selecteer vervolgens het databasebestand TasksTest.mdf en kies OK. Vanuit de Server Explorer kunnen we nu een tabel met de naam TasksTestData toevoegen. De tabeldefinitie staat in figuur 6.

Fig. 6: Tabeldefinitie voor TasksTestData

Zodra de tabel bewaard is kunnen we gegevens invoeren. Open de tabel (rechtermuisknop op de tabel en dan Show Table Data) en voer de volgende waarden in:

Fig. 7: Testwaarden voor het testen van voortgang

Nu we gegevens in de tabel hebben, moeten we deze koppelen aan de test UpdateProgressTest(). Vanuit het eigenschappen-venster van UpdateProgressTest() vul je de Data Connection String-eigenschap en de Data Table Name-eigenschap. De complete test ziet er als volgt uit:

  "…[complete connectiestring]…", _
  "TasksTestData", _
  DataAccessMethod.Sequential)> _
    _
  Public Sub UpdateProgressTest()
    Dim myException As Exception = Nothing
    Dim taskName As String = _
      TestContext.DataRow("Name").ToString()
    Dim progress As Integer = _
      Convert.ToInt32(TestContext.DataRow("Progress"))
    Dim myTask As Task = New Task(taskName)
    Try
      myTask.UpdateProgress(progress)
    Catch ex As Exception
      myException = ex
    End Try

    If Not myException Is Nothing Then
      Assert.AreNotEqual(GetType(ArgumentException), _
        "Deze exceptie was niet verwacht.")
    Else
      If progress = 0 Then _
        Assert.AreEqual(myTask.Status, _
          TaskStatus.NotStarted)
      If progress > 0 And progress < 100 Then _
        Assert.AreEqual(myTask.Status, _
          TaskStatus.InProgress)
      If progress = 100 Then _
        Assert.AreEqual(myTask.Status, _
          TaskStatus.Finished)
      End If
  End Sub

Het eerst dat opvalt is de toevoeging van het attribuut DataSource waarin de connectiestring, de tabelnaam en de volgorde zijn vastgelegd. Daarnaast zijn de TextContext.DataRow instructies van belang. TestContext is een object dat gegenereerd is via de Create Tests wizard. Dit object wordt automatisch geïnstantieerd tijdens de uitvoering van de test zodat we gerelateerde data kunnen benaderen (zie figuur 8).

Fig. 8: De TestContext klasse als eigenschap van TaskTest

Het TestContext-object biedt gegevens zoals de TestDirectory en TestName met methoden als BeginTimer() en EndTimer(). Voor de test UpdateProgressTest is de DataRow-eigenschap van belang. Omdat UpdateProgressTest het attribuut DataSource kent, zal de methode voor iedere regel in de tabel, ook opgegeven in DataSource, worden aangeroepen. Zo kan programmacode getest worden voor een reeks gegevens. Met zes records in de tabel wordt de test dus 6 keer uitgevoerd.

Het is op deze manier dus erg makkelijk om extra testcases toe te voegen. We hoeven enkel maar testwaarden op te geven in de tabel. We kunnen ook twee tabellen hanteren. Eentje met correcte waarden en eentje zonder, maar in een geïntegreerde test kan met een beetje extra werk getest worden op beide soorten gegevens.

Nu we de test gemaakt hebben, is het zaak de implementatie te schrijven. Eerst voegen we aan het project een enumeratie toe voor de verschillende mogelijkheden van de TaskStatus.

Public Enum TaskStatus
  NotStarted
  InProgress
  Finished
End Enum

Daarna schrijven we de UpdateProgress-methode, als onderdeel van de Task-klasse.

Public Sub UpdateProgress(ByVal progress As Integer)
  If progress > 100 Or progress < 0 Then _
    Throw (New ArgumentNullException( _
      "Waarde moet tussen 0 en 100 zijn."))
  Select Case progress
    Case 0
      m_status = TaskStatus.NotStarted
    Case 100
      m_status = TaskStatus.Finished
    Case Else
      m_status = TaskStatus.InProgress
  End Select
  m_progress = progress
End Sub

Code coverage

Het is belangrijk om vast te stellen hoeveel van de programmacode getest is. Dit kunnen we doen aan de hand van zogeheten code coverage. Standaard staat de code coverage-analyse niet aan. Via Test > Edit Test Run Configurations > Local Test Run kunnen we dit aanzetten in het tabblad Code Coverage. De analyse vindt alleen plaats op de geselecteerde assemblies en ook alleen als de uitvoering van de test zonder debugging plaatst vindt (dus Ctrl-F5 of Debug > Start Without Debugging). Na het uitvoeren van de test kan via Test > Windows > Code Coverage Results bekeken worden hoeveel van de programmacode getest is (zie figuur 9).

Fig. 9: Code Coverage Results

De programmacode zelf is ook gearceerd: groen voor instructies die wel zijn uitgevoerd, rood voor niet geteste instructies. De kleuren kunnen wat afwijken, omdat dit een persoonlijke instelling is.

Op deze manier is eenvoudig te achterhalen of er programmacode in het project zit dat niet volgens de TDD-regels is gemaakt.

Initialisatie en opruimen

Wellicht heb je al vastgesteld dat testen individueel worden uitgevoerd. Het is ook af te raden om testen te maken die verplicht in een bepaalde volgorde moeten worden uitgevoerd. Maar het kan wel zijn dat meerdere testen gebruik maken van een bepaalde database-verbinding of XML Web Service. Het initialiseren van zo’n verbinding kan tamelijk kostbaar zijn, en het is dan niet efficiënt om bij enkele tientallen testen achter elkaar telkens opnieuw een database-verbinding te creëren.

Het is daarom mogelijk om bepaalde methoden te markeren met een attribuut zodat deze methode aan het begin van een testrun worden uitgevoerd. Zo ook natuurlijk aan het eind, met een andere attribuut. Dit zijn respectievelijk de attributen ClassInitialize() en ClassCleanup(). Het is ook mogelijk om iedere test vooraf te laten gaan van een methode en een afsluiting. Hiervoor gebruiken we de attributen TestInitialize() en TestCleanup().

Best Practices

Er zijn verschillende best practices die we kunnen hanteren bij het gebruik van unit testen. Test-driven development is een inmiddels niet meer weg te denken ontwikkelmethodiek. Voor Visual Basic programmeurs is het onderscheid tussen RAD en TDD niet altijd even makkelijk te maken. Bij RAD begint men eerst met het maken van enkele schermen, zetten er buttons, lijsten, labels en invoervelden op. Vervolgens begint de implementatie. Het scherm lijkt wel de unit test. Er zijn echter wel grote verschillen:

• unit testen richten zich meestal op de business-logica in een project;
• een test kan op ieder moment en geheel geautomatiseerd worden uitgevoerd;
• het testresultaat is ondubbelzinnig en er kan makkelijk over gerapporteerd worden.

Het invoeren van unit testen in een ontwikkeltraject kost in het begin wat extra discipline, maar na verloop van tijd gaat het vanzelf en kun je eigenlijk niet meer zonder

Het invoeren van unit testen in een ontwikkeltraject kost in het begin wat extra discipline, maar na verloop van tijd gaat het vanzelf en kun je eigenlijk niet meer zonder. Voor de testen zelf gelden nog wat aanbevelingen en richtlijnen:

• Zorg er voor dat er geen afhankelijkheden, al dan niet ten aanzien van de volgorde, zijn tussen de testen. Iedere test moet op zichzelf uitgevoerd kunnen worden;
• Schrijf eerst testen voor het implementeren van enige programmacode;
• Maak een testklasse per klasse in de programmacode. Zodoende is het testproject makkelijk te beheren en hoef je niet telkens een keuze te maken waar de test geplaatst moet worden.
• Gebruik Visual Studio om het initiële testproject te genereren. Dat scheelt een hoop werk ten opzichte van het handmatig toevoegen en instellen.
• Vermijd zo mogelijk machineafhankelijke testen, zoals een test die afhankelijk is van een bepaalde folder. Geen “maar het werkt op mijn PC!”. 
• Stel vast dat alle testen succesvol zijn voor je een nieuwe test toevoegt. Zodra programmacode breekt, is het aan te raden deze direct te herstellen.
• Probeer zo veel mogelijk testen te maken die automatisch kunnen worden uitgevoerd. Handmatige testen moeten vermeden worden.
• Een test moet liefst zo snel mogelijk uitvoerbaar zijn. Als een test langzaam is, wordt deze veelal niet vaak uitgevoerd.
• Zorg ervoor dat een testmethode slechts één onderdeel test. Dat wil zeggen, maak de scope van een test zo klein mogelijk zodat duidelijk is wat er mis is zodra een test faalt.

Conclusies

In het algemeen kan gesteld worden dat de unit test mogelijkheden in Visual Studio Team System uitgebreid zijn, en zelfs nog verder kunnen worden uitgebreid met third party mogelijkheden. Met code coverage hebben een prima blik op de mate waarin de testen werkelijk de geschreven programmacode controleert. Bovendien kan het aantal testen gerelateerd worden aan het aantal fouten of de hoeveelheid programmacode. Op die manier beschikken we over een aardige indicator van de status van een project.

We hebben in dit artikel gekeken naar het doel en het kader van unit testen. Het voorbeeld, met een eenvoudige opzet maar uitgebreid met testen op basis van een database, heeft getoond wat de mogelijkheden zijn. Door vroeg te beginnen unit testen op te nemen in de ontwikkeling van programma’s ontstaat een testset die op langere termijn bijzonder waardevol zal zijn. De integratie van testen in Visual Studio en bijvoorbeeld Team Foundation Server maakt het gebruik ervan eenvoudig en handig.

Meer informatie

• Test-Driven Development in Microsoft .NET, James Newkirk, Microsoft Press.
• www.nunit.org
• www.testdriven.net
• Testing Methodologies, MSDN, sdn.urlproxy.com/1

Sources

De sources die bij dit artikel horen kunt u downloaden via Gerz_UnitTesting_SRC.zip.