WAT IS EEN UNIT TEST? Een unit test is een test om de functionaliteit van stukken code te controleren. Een goede unit test waarborgt een consistente werking van een klein onderdeel (een ‘unit’) van de broncode.
WAT IS EEN ‘GOEDE’ UNIT TEST •
Automatisch en repeterend te draaien
•
Makkelijk te implementeren, makkelijk te maken
•
Iedereen moet het kunnen draaien
•
Toekomstgericht
•
Snel en met 1 druk op de knop te draaien
Een unit test is geen integratie test. Niet het hele systeem, maar onderdelen van een systeem worden getest.
HET OPZETTEN VAN EEN SIMPELE UNIT TEST Laten we starten met het maken van een unit test voor de volgende unit: unit uTestableUnit; interface type TCalculator = class public function Sum(a:integer; b:integer): integer; end; implementation { TCalculator } function TCalculator.Sum(a, b: integer): integer; begin result := a + b; end; end. De enige functie in deze unit is het optellen van twee getallen. Om deze functie te testen via de klassieke manier in Delphi moet er een DUnit project aangemaakt worden. Om in Delphi een DUnit project aan te maken, klikken we op File -> New -> Other. Selecteer “Test Project” in het menu “Unit Test”.
De DUnit wizard wordt nu getoond, waarbij het mogelijk is om de locatie van de unit test op te geven. Ook kan er gekozen worden uit het aanmaken van een GUI of een console project.
Voorlopig gebruiken we de GUI, de console is vooral handig bij het koppelen van unit testen aan automatische systemen zoals Finalbuilder. Na een klik op Finish wordt het unit test project aangemaakt. De volgende stap is het toevoegen van unit testen. Dit doen we door te klikken op File -> New -> Other. In het “unit test” menu is nu de optie “Test Case” toegevoegd.
Bij het aanmaken van een Test Case wordt er opnieuw een wizard getoond. Kies in deze wizard de aangemaakte uTestableClass.pas. De wizard zal vervolgens structuur van de class aangeven, waarna we de mogelijkheid krijgen om een functie te selecteren die we willen testen. Kies voor onze functie “Sum” en klik op Finish om de Test Case aan te maken.
Voor de functie Sum is er nu een nieuwe unit aangemaakt, waarin we de Test Case kunnen definiëren. In het implementation gedeelte van de nieuwe unit kunnen we de volgende code vinden: procedure TestTCalculator.TestSum; var ReturnValue: Integer; b: Integer; a: Integer; begin // TODO: Setup method call parameters ReturnValue := FCalculator.Sum(a, b); // TODO: Validate method results end; Zoals het commentaar al aangeeft zullen we de parameters moeten specificeren en het resultaat moeten valideren. Laten we dat eens doen voor een eenvoudige som: procedure TestTCalculator.TestSum; var ReturnValue: Integer; b: Integer; a: Integer; begin // TODO: Setup method call parameters a := 1; b := 2; ReturnValue := FCalculator.Sum(a, b); // TODO: Validate method results CheckEquals(3,ReturnValue); end; Het zetten van de twee parameters voor onze functie spreekt voor zich, a heeft de waarde 1 en b de waarde 2. De uitkomst van onze functie Sum moet dus 3 zijn. De controle of dit ook zo is kunnen we doen door het aanroepen van de speciale Check functies van DUnit. In dit geval gebruiken we CheckEquals, maar voor andere returnvalues zijn er ook andere Checks beschikbaar:
Wij hebben hier de functie CheckEquals gebruikt om te controleren of de waarde van onze returnvalue overeenkomt met het verwachte resultaat 3. Om deze Test Case te testen, moeten we het Test Project runnen. Aangezien we de GUI variant gekozen hebben zien we bij het runnen onderstaand scherm:
Hierbij zijn al onze aangemaakt Test Cases te zien, in dit gebruik alleen de TestSum procedure. Het runnen van de Tests kan door middel van het klikken op de groene “run” knop. Als we alles goed aangemaakt hebben zullen we onderstaand scherm zien:
Alles testen zijn nu doorlopen en er zijn geen fouten gevonden.
OPLOSSEN VAN BUGS Stel nu dat de implementatie van onze functie Sum aangepast wordt. De nieuwe code wordt: unit uTestableUnit; interface type TCalculator = class public function Sum(a:integer; b:integer): integer; end; implementation { TCalculator } function TCalculator.Sum(a, b: integer): integer; begin result := a + b + 1; end; end. De compiler zal over onze nieuwe functie Sum geen enkele melding afgeven, het is tenslotte geldige Delphi code. De implementatie is echter wel aangepast. Alle functies die gebruik maken van onze functie Sum zullen nu dus een probleem hebben. Laten we nu hetzelfde Test Project nogmaals draaien. De uitkomst daarvan bepaald namelijk of de logica in onze functie nog steeds hetzelfde is. Als we het Test Project runnen en weer op de groene knop klikken, ziet ons resultaatscherm er heel anders uit:
We testen onze verwachte uitkomst (3), maar we krijgen de waarde (4) terug! Blijkbaar hebben we met onze aanpassen een fout gemaakt, waardoor de functie ineens anders is gaan werken. Nu is bovenstaand voorbeeld natuurlijk erg eenvoudig, en iedereen kan direct de fout zien. Bij het gebruik van complexere applicaties zijn de functies en procedures echter ook complexer. Dit betekent dat de werking van een functie niet altijd direct duidelijk hoeft te zijn. In dat geval is het een hele geruststelling als er unit testen aanwezig zijn die de logica van een applicatie op unit niveau bewaken.
GEÏNTEGREERDE UNIT TESTEN IN DELPHI Met bovenstaande voorbeelden is het wel duidelijk: iedere serieuze programmeur moet het gebruik van unit testen overwegen. Het aanmaken en beheren van de unit tests op de klassieke manier is echter relatief veel werk. De testen moeten uitgevoerd worden in een ander project, en de resultaten van de testen zijn niet één oogopslag tijdens het ontwikkelen te zien. Daarvoor heeft GDC Software TestGrip ontwikkeld. Met TestGrip is het mogelijk om de unit testen vanuit het actieve project in Delphi aan te maken, te runnen en te onderhouden. TestGrip is eenvoudig te installeren. Tijdens de installatie wordt de keuze gegeven voor welke versie van Delphi TestGrip geïnstalleerd kan worden.
Na de selectie van de Delphi versies en het klikken op Next wordt TestGrip geïnstalleerd en direct geïntegreerd in Delphi.
Bij de eerste keer opstarten van Delphi is TestGrip nog niet direct zichtbaar. TestGrip kan namelijk op iedere plaats in de IDE gedocked worden. Om TestGrip op een vaste plaats in de Delphi IDE vast te zetten, moeten we eerst een project openen. Nadat er een unit in de Delphi IDE open staat, verschijnt TestGrip in de menubalk van de IDE.
Door het klikken op TestGrip -> Show zal het basisformulier van TestGrip getoond worden
Dit formulier is dockable, dat wil zeggen dat het op iedere plaats in de Delphi IDE vast te zetten is. Na het vastklikken van het formulier moet de huidige desktop/IDE configuratie van Delphi worden opgeslagen. Dit kan door middel van het klikken op de knop "Save current desktop" button in the IDE.
Doen we dit niet, dan zal bij de volgende keer starten TestGrip opnieuw getoond moeten worden door het klikken op TestGrip -> Show. Nu TestGrip op de goede plaats staat kunnen we starten met het aanmaken van onze eerste test via TestGrip. Laten we de code nog even bekijken: unit uTestableUnit; interface type TCalculator = class public function Sum(a:integer; b:integer): integer; end; implementation { TCalculator } function TCalculator.Sum(a, b: integer): integer; begin result := a + b + 1; end;
end. De foute berekening laten we voor het gemak nog even staan. Als we voor deze functie Sum een test willen aanmaken, kunnen we dit nu direct vanuit TestGrip doen. Ga hiervoor met de cursor in de editor in de functie Sum staan (in de implementatie). In TestGrip wordt nu de actieve functie getoond (TCalculator.Sum):
Door middel van het klikken op de groene + knop, zal TestGrip een unit test aanmaken. In de popup worden de parameters van onze functie gevraagd (2 integers) en moet het verwachte resultaat worden opgegeven.
Na het klikken op “save” is de unit test aangemaakt. De unit test is te zien in TestGrip en met één druk op de knop te runnen. Zolang de test nog niet uitgevoerd is zal de treeview met alle testen nog rood zijn. Iedere test die geslaagd is wordt groen weergegeven. Indien een test faalt (wat in ons geval zo is) wordt het resultaat van de test ook direct in TestGrip weergegeven.
Omdat TestGrip altijd zichtbaar is vanuit de IDE, is het als programmeur veel makkelijker om het aanmaken en controleren van unit testen te combineren met het ontwikkelen van functionaliteit.
GEAVANCEERDE TESTEN
Een simpele functie zoals de som van twee getallen is natuurlijk eenvoudig te testen. Juist bij complexere procedures en functies zijn unit tests zinvol. We gaan eens kijken naar een uitgebreidere class. Het hele project, met alle unit testen, wordt bij de installatie van TestGrip meegeleverd, en is te vinden onder het menu TestGrip -> Demo project. // Forward declaration for using TWorldObject in TWorld TWorldObject = class; // Our main class TWorld = class strict private FWorldObjectList: TList; FWorldName: string; public constructor Create; destructor Destroy; override; // Functions to add and delete objects function AddWorldObject(aWorldObject: TWorldObject): integer; function DeleteWorldObject(WorldObjectIndex: integer): boolean; // and to get a specific object function GetWorldObjectItem(WorldObjectIndex: integer): TWorldObject; function WorldObjectCount: integer; property Name: string read FWorldName write FWorldName; end; // All objects derive form this class TWorldObject = class private FName: string; public property Name: string read FName write FName; end; // Some objects are alive TLivingWorldObject = class(TWorldObject) private FBirthDate: TDateTime; FParent: TLivingWorldObject; public constructor Create; // We could use properties here, but instead we use overloaded functions // to demo the unit tests of this type of functions procedure SetBirthDate(aDate: TDateTime); overload; procedure SetBirthDate(YearsOld: integer); overload; function Age: integer; function IsBorn: boolean; // Use the reproduce function to create another instance of a TLivingWorldObject // with the same name, but a birthdate of now()
function Reproduce: TLivingWorldObject; // Only available when the instance is created via the function Reproduce function Parent: TLivingWorldObject; end; In dit voorbeeld hebben we een drietal objecten: TWorld, TWorldObject en TLivingWorldObject. De laatste is afgeleid van TWorldObject. Om het complete project hier te behandelen zou teveel ruimte vergen, vandaar dat we er een aantal functies uit willen lichten. Om bij een relatief eenvoudige functie te beginnen, door middel van de functie AddWorldObject kunnen we objecten van het type TWorldObject aan onze wereld toevoegen. function TWorld.AddWorldObject(aWorldObject: TWorldObject): integer; begin result := FWorldObjectList.Add(aWorldObject); end; FWorldObjectList is de lijst waarin alle objecten in de wereld opgeslagen worden. De instantie van de FWorldObjectList is bij de create van onze wereld geregeld, dus we kunnen hier veilig het aWorldObject aan de lijst toevoegen. Als resultaat geven we de index van het object in de lijst terug. Voor deze functie maken we twee eenvoudige testen. Eén waarbij AddWorldObject wordt aangeroepen als er nog geen objecten in FWorldObjectList aanwezig zijn, en één waarbij dat wel het geval is. We willen er namelijk zeker van zijn dat we altijd de juiste index terug krijgen. De eerste test is eenvoudig te maken; ga met de cursor in de functie staan en klik op de groene + knop in TestGrip. In de popup dienen we vervolgens de parameter aWorldObject te specificeren en het resultaat van de functie te valideren. Omdat ons type TWorldObject eenvoudig is, kunnen we aWorldObject op de volgende manier initialiseren:
Als value bij onze parameter aWorldObject geven we TWorldObject.Create in. Hiermee wordt er een instantie van aWorldObject aangemaakt en doorgegeven aan de functie AddWorldObject. Bij het resultaat (equals) geven we 0 op; het is het eerste object wat aan onze lijst toegevoegd wordt. Na een klik op “save” kunnen we testen of onze Test Case werkt. Voor de tweede test hebben we de advanced settings van TestGrip nodig. We willen namelijk eerst een paar andere objecten aan de FWorldObjectList toevoegen, voordat we de functie AddWorldObject aanroepen. Op die manier kunnen we zien of het toevoegen van een object ook een andere index geeft. Om dit te doen klikken we opnieuw op de groene plus in TestGrip. Voordat we de value van aWorldObject gaan vullen, openen we de advanced settings.
In het advanced settings scherm vinden we een aantal opties en tabbladen om de test verder uit te breiden. Er zijn drie verschillende tabbladen met dezelfde informatie. Bij zowel de class settings, de function settings en de test settings kan extra initialisatie code opgegeven worden. De initialisatie kan gebruikt worden om een aantal zaken goed te zetten, voordat de test uitgevoerd wordt. In dit voorbeeld roepen we een aantal keer de AddWorldObject functie aan, om de variabele FWorldObjectList te vullen. Op dit moment is deze initialisatie gevuld bij het “Test Settings” tabblad. Dit betekent dat deze initialisatie alleen voor deze specifieke test uitgevoerd wordt. Zouden we de initialisatie bij het tabblad “Function settings” neerzetten, dan wordt deze initialisatie bij iedere unit test van deze functie uitgevoerd. Dit kan handig zijn als er bepaalde initialisatie van een functie altijd gedaan moet worden. Ditzelfde geldt natuurlijk bij de initialisatie van een class, stukken code die altijd uitgevoerd moeten worden bij alle testen binnen deze class kunnen daar neergezet worden. Nu we in de advanced settings mode zitten, kan het soms handig zijn om te zien hoe TestGrip de test opbouwt. Hiervoor is de knop “Show code view” toegevoegd. Met “Show code view” wordt een weergave gemaakt van de opbouw van de unit test, zoals TestGrip deze op de achtergrond gebruikt.
Deze code is niet aan te passen, omdat het hier om gegenereerde code gaat. TestGrip gebruikt deze code echter wel om de testen uit te voeren, het kan dus handig zijn om af en toe te bekijken hoe de test opgebouwd wordt. Nu deze twee testen aangemaakt zijn, wordt het tijd om te kijken naar de andere opties van TestGrip. In TestGrip is het mogelijk om “Test Implies” op te geven. Met ‘Test Implies” kunnen geavanceerdere controles worden toegevoegd die na het uitvoeren van de functie gecontroleerd worden. Deze controles kunnen handig zijn om een complex resulttype van een functie te testen. Als voorbeeld nemen we de volgende functie:
function GetWorldObjectItem(WorldObjectIndex: integer): TWorldObject; Door middel van deze functie kunnen we objecten uit de FWorldObjectList opvragen, het resulttype is een TWorldObject. De implementatie van de functie is als volgt: function TWorld.GetWorldObjectItem(WorldObjectIndex: integer): TWorldObject; var WorldObject: TWorldObject; begin if WorldObjectIndex > FWorldObjectList.Count -1 then begin result := nil
end else begin WorldObject := TWorldObject(FWorldObjectList.Items[WorldObjectIndex]); if assigned(WorldObject) then result := WorldObject else result := nil; end; end; In dit voorbeeld geven we NIL terug indien het object niet gevonden kan worden, en de instantie van TWorldObject als we het object wel terug vinden. Voor deze functie zijn er minimaal twee testen nodig: de controle of er ook daadwerkelijk nil terug gestuurd wordt indien er geen object is, en de controle of het resultaat bij een geldige index van het type TWorldObject is. Laten we eerst de nil-test maken. Door het klikken op de groene + knop maken we een nieuwe test aan. Omdat we de functie met als resultaat NIL willen testen, hoeven we geen uitgebreide test aan te maken; default is de FWorldObjectList namelijk leeg. Het volstaat dus om de index op 0 (of een willekeurig getal) te zetten en de equals op NIL te zetten.
Voor het testen van het resultaat met als type TWorldObject zullen we wel een wat uitgebreidere test moeten maken. In de gebruikte FWorldObjectList moeten namelijk minimaal een paar elementen aanwezig zijn. Nu kunnen we deze objecten op meerdere manieren in de lijst zetten. De makkelijkste manier is om dit bij de initialisatie van de test te doen. Hiervoor hebben we een aantal variabelen nodig die geïnitieerd kunnen worden. Het vermelden van de variabelen doen we op de geavanceerde weergave, in het tabblad variabele declarations:
In dit voorbeeld zijn er drie variabelen aangegeven van het type TWorldObject. Deze moeten uiteraard nog geïnitialiseerd worden. Dit doen we op het tabblad Test Settings als volgt: TestObj := TWorld.Create(); WorldObj1 := TWorldObject.Create; WorldObj1.Name := 'Test1'; WorldObj2 := TWorldObject.Create; WorldObj2.Name := 'Test2'; WorldObj3 := TWorldObject.Create; WorldObj3.Name := 'Test3'; TestObj.AddWorldObject(WorldObj1); TestObj.AddWorldObject(WorldObj2); TestObj.AddWorldObject(WorldObj3); Hiermee worden de objecten aangemaakt en aan ons algemene TestObj (van het type TWorld) toegevoegd. Nu er een aantal elementen in de FWorldObjectList van het object TestObj staan, wordt het tijd om het resulttype te testen. Omdat dit een complex resultaat is (dus geen eenvoudige string of integer bijvoorbeeld) gaan we dit testen door middel van de implies. In de implies kunnen we gebruik maken van de variabele testResult, waarin het resultaat van de functie zit. Omdat we ook de equals op moeten geven, kunnen we daar controleren of het resultaat van de functie niet NIL is, door middel van het ingeven van NIL bij de equals en het vinkje “not” aan te vinken. Hiermee controleert TestGrip of het resultaat ongelijk aan NIL is. De controle of het resultaat object kunnen we doen door in de implies te controleren of we de juiste instantie e van het gevraagde object terug krijgen. Stel dat we het 3 object terug willen krijgen, moeten we bij de ingave e van de parameter voor het cijfer 2 kiezen (we starten bij 0, dus 2 is het 3 object). Het resultaat moet vervolgens van het type TWorldObject zijn, met als naam ‘Test3’.
Bij de implies kunnen we overigens meerdere regels ingeven, dus het is ook mogelijk om bij de implies andere waardes van ons object te testen. Indien 1 van de implies faalt, dan wordt deze hele unit test als gefaald aangemerkt. Met TestGrip is het dus heel eenvoudig om zowel eenvoudige als complexe unit testen aan te maken en te gebruiken in de Delphi IDE. Na aanpassingen in de broncode is het testresultaat met één druk op de knop zichtbaar. Daarnaast beschikt GDC TestGrip over meerdere handige functies om het werken met unit tests zo eenvoudig mogelijk te maken. Zo zijn er sneltoetsen voor het toevoegen en runnen van een unit test, is het mogelijk om direct naar de functie te springen van een gefaalde unit test en is GDC TestGrip te koppelen met Continuous Integration systemen zoals Finalbuilder. Een proefversie van GDC TestGrip is te downloaden via http://gdcsoftware.com/downloads/Setup_TestGrip_Trial.exe In the next article we are going to take a look at the other functions of TestGrip and the integration of TestGrip with Continuous Integration systems, such as Finalbuilder.
Bio:
Marco Geuze heeft meer dan 15 jaar ervaring in het ontwikkelen in Delphi en Object Pascal. Als freelance ontwikkelaar is Marco in 2006 gestart met Geuze Automatisering, gericht op het ontwikkelen van maatwerk applicaties in de talen Delphi en PHP. Inmiddels is Marco mede eigenaar van GDC Software en is Geuze Automatisering gegroeid naar een bedrijf met meerdere ontwikkelaars en een brede klantenkring.
Voor meer informatie over TestGrip en unit testen, ga naar www.gdcsoftware.com www.geuzeautomatisering.nl
