Unit- & Regressietesten in Visual FoxPro – deel 3 van 3
In de eerste en tweede delen van dit artikel heb ik automatisch testen in het algemeen besproken, en heb ik een tool voor het automatisch testen van Visual FoxPro code de revue laten passeren: VFPUnit.
In dit laatste deel laat ik een aantal geavanceerde functies van VFPUnit zien, waarna ik het voorgaande kort zal samenvatten en mijn conclusies aan u zal presenteren. Mijn hoop is dat u, na het voltooien van deze tutorial, het automatisch testen van uw programmacode serieus in overweging zult nemen.
Tutorial: Het onderwerp van de test
Het onderwerp van de test betreft het echte werk dat u nu gaat testen: de source-code met zijn logica. Bij het Test-First-paradigma zal dit sourcebestand waarschijnlijk nog niet eens bestaan, maar heeft u al wel een reeks tests gedefinieerd. In dat geval is uw specificatie gereed en is het nu tijd om aan de implementatie van uw systeem te beginnen.
De Source knop in het Experiment-venster laadt de unit die getest gaat worden.
Klik op New om een nieuw sourcebestand te definiëren of om een bestaande te laden.
Klik vervolgens op Save, gevolgd door Select om de Source Unit in uw test te laden.
De test is nu aan het sourcebestand gekoppeld.
Onder de motorkap
Wanneer u een source aan uw test heeft gekoppeld, voert VFPUnit een SET PROCEDURE|CLASSLIBRARY TO uit, elke keer vóór de test gedraaid wordt.
De Modify knop laat u de code van de unit bewerken.
Het nieuwe myprogram.prg, dat u als een testsource heeft gedefinieerd, kunt u meteen met alle functionaliteit in Visual FoxPro bewerken.
U ziet dus dat het desgewenst mogelijk is om, direct vanuit VFPUnit, aan het coderen van een splinternieuwe klasse te beginnen, de ware geest van test-first development.
Work In Progress
De knop Subject in het Experiment- venster is nog in aanbouw. De bijbehorende vakjes Class en Method zijn dus in deze versie nog niet bruikbaar.
Tutorial: Fixtures
Fixtures – de “vaste structuur” om een reeks unit tests heen
Een fixture is eigenlijk datgene wat een reeks gerelateerde tests gemeen heeft. Hierbij kunt u b.v. denken aan de te testen klassen en de omgeving waarin de test zich verkeert. De omgeving wordt weerspiegeld in de Fixture Setup en Teardown.
Hier wordt een variant getoond van het laden van uw test-subject als een source-file, namelijk het laden van de nodige bestanden in een fixture.
Door op de knop Save te klikken wordt zowel de test als de nieuwe fixture bewaard.
Dit had ook gekund door op de knop Fixture te klikken, en vervolgens in het venster Fixtures achtereenvolgens op de knoppen New en Save te klikken, nadat een naam is ingevoerd.
De klasse Fixture:
De klasse Fixture heeft de volgende eigenschappen:
- Description: een korte omschrijving van de fixture
- Properties/Resources: definieer hier attributen van de Fixture klasse
- Setup: deze code wordt vóór de Test Code uitgevoerd
- Teardown: deze code wordt ná de Test Code uitgevoerd
De knop Fixture Code in het Experiment-venster geeft het venster Fixture weer, waarin deze onderdelen apart kunnen worden bewerkt:
PS: Fixtures worden separaat van de unit tests bewaard en kunnen dus door meerdere tests worden gebruikt.
U ziet dat een fixture ook over Class_Properties beschikt. Dat een fixture ook daadwerkelijk in uw test een object, met properties en methoden is, ziet u in de volgende paragraaf.
Tutorial: een kijkje onder de motorkap
- Het sleutelwoord Fixture verwijst naar het Fixture-object, met de bijbehorende Properties/Resources, Setup en Teardown secties.
- THIS verwijst naar het unit test object zelf.
- De Test Code wordt geplaatst in de methode THIS.MyRun()
Extra functies (methoden van THIS) en zelfs extra klassen kunnen onderin de Test Code worden gedefinieerd. Houd hierbij het volgende in de gaten:
- Vergeet niet om deze methoden in uw testcode met THIS. vooraf te laten gaan!
- Methoden en klassen in uw Test Code moeten aan het einde van de Test Code worden gedefinieerd.
- Wanneer u een klasse in een fixture definieert, moet deze aan het einde van de Teardown sectie worden gedefinieerd. In zo’n geval moet het object ook in de Setup sectie van de fixture worden gedefinieerd en aan een property van de fixture worden toegewezen. Deze property dient vervolgens gedurende de test te worden aangesproken (zie “Packaging/Refactoring” hieronder in de sectie “Geavanceerde onderwerpen”).
Tutorial: Extra's
De knop Statements >> boven de Test Code in het Experiment- venster geeft een overzicht van alle sleutelwoorden en constanten.
Het sleutelwoord STOP opent de VFP debugger; de xonstanten KCR en KCRLF geven regelovergangen weer. Deze entiteiten kunnen m.b.v. drag and drop in de “Test Code” (“Sample”) venster worden neergezet.
Hetzelfde geldt overigens ook voor sleutelwoorden die in een fixture van toepassing zijn. De knop Statements >> boven de Fixture Code in het Experiment-venster geeft een overzicht van alle sleutelwoorden en constanten die in een fixture kunnen worden gebruikt.
Test For Truth, Scream Injustice
Tutorial: Tips & tricks
“Test For Truth, Scream Injustice”
- lSuccess moet evalueren tot de waarde .T.
- Laat cFailMessage aangeven wat er bij een test misging
Probeer een test zo specifiek mogelijk te maken
- Geen abstracte/generieke oplossingen – het moet meteen duidelijk worden wat de casus van de test is. Het gaat erom dat een test één specifieke casus uit uw specificaties test.
- Hardcodeer alle waarden, portabiliteit speelt geen rol – u test tenslotte maar één “unit” per test.
Een test dient in eerste instantie te falen
- Bij “Test First” moeten de fouten de ontwikkeling aansturen.
- Hier wordt een baseline (benchmark of meetpunt) vastgesteld.
- De tests bepalen ten eerste wat er gecodeerd moet worden (het probleemdomein/de analyse) en later pas hoe (het ontwerp).
Schenk ook aandacht aan de “grensgevallen”
- Hier gaan programma's heel vaak mee de mist in!
*!* Breng commentaar aan, ook in uw testcode *!*
- Dit moet ook niet vergeten worden. Uw tests dient u met net zoveel zorg te maken als uw productiecode – de tests zijn immers een cruciaal onderdeel van uw Quality Assurance beleid en zullen ongetwijfeld ook vaak opnieuw bezocht worden (zeker aangezien u ze niet ‘generiek’ heeft gemaakt!)
Testdata Bed
- Maak een kopie van een deelverzameling van eventueel reeds aanwezige productiedata. Dit geeft u snel en gemakkelijk beschikking over realistische gegevens om mee te testen.
- Hardcodeer de locatie van de testdatabase – hierin kunt u zich geen fouten permitteren! Bedenk weer dat u niet met een generieke oplossing bezig bent maar met een specifieke test voor een specifieke klasse of unit. De klassen uit uw persistence framework kunnen hiervoor heel gemakkelijk in uw Fixture Setup worden geïnitialiseerd.
Tutorial: Geavanceerde Onderwerpen
Packaging/Refactoring
- Gebruik een functie in de Test Code voor algemene functionaliteit die voor deze test nodig is, maar die in het Source File ontbreekt.
- Definieer een klasse in de Test Code om snel en gemakkelijk een “wrapper” of een “adapter” van een bestaande klasse te maken.
- Fixtures neigen ertoe om business objecten te worden (of façades). Functies binnen een fixture duiden op methoden van dit business object, en klassen binnen een fixture suggereren dat het business object een composite wordt.
Wie schrijft die blijft
Conclusies
Wie schrijft die blijft
Wie de moeite neemt om geautomatiseerde unit tests te maken heeft wel wat. Het lijkt in eerste instantie een hoop werk, maar bij de eerste iteratie zult u al merken dat u effectiever werkt – het is immers meteen duidelijk wanneer uw software doet wat het moet doen. Bij volgende iteraties en nieuwe versies, waaronder refactoring-werkzaamheden, bent u verzekerd van een tijdige waarschuwing wanneer uw software door een onbedoelde wijziging per abuis stuk is gemaakt. In samenwerking met een versiebeheersysteem zoals Microsoft Visual SourceSafe heeft u de kracht en de kennis om de oorzaak van nieuw geïntroduceerde fouten op te sporen.
Test First: de fouten leiden het ontwikkelproces
De tests weerspiegelen in eerste instantie de belangrijkste elementen uit de analyse en bepalen vervolgens hoe het systeem zich precies moet gedragen.
Links / Referenties
VFPUnit
- Voor de download en een uitgebreide tutorial: http://www.geocities.com/larryteske/vfpunitdoc10.html
- VFPUnit kan ook van de website van de SDN bij dit artikel worden gedownload. Dit bestand Dwyer_VFPUnit.zip (588kb) bevat, naast een schone versie van VFPUnit die gereed is voor productiegebruik is, ook een exemplaar van VFPUnit waarin de volledige tutorial reeds is uitgewerkt. U hoeft dus niets te typen om te zien hoe alle facetten van VFPUnit werken.
SDN Magazine nr. 78:
- Algemeen artikel over het testen door Harry Vroom op blz. 12.
- Artikel over JUnit door Wico Mulder op blz. 10 voor een voorbeeld van een vergelijkbare testframework voor Java.
Voor een introductie tot Extreme Programming:
Refactoring:
Voor vragen kunt u bij Muhammad Dwyer terecht (e-mail: muhammad@zonnet.nl) of bij Larry Teske (website: http://www.geocities.com/larryteske/).
Klik hier voor deel 1 van dit artikel.
Klik hier voor deel 2 van dit artikel.