Framework for Integrated Test
Het Framework for Integrated Test (of FIT) is een concept in het ontwikkelen en testen van computerprogramma's ontwikkeld door Ward Cunningham, Rick Mugridge en andere medewerkers van het Amerikaanse consultantcy-bedrijf Object Mentor.
Basisconcept bewerken
FIT is gebaseerd op Extreme Programming en andere Agile methoden.
Het basisconcept van FIT is dat het ontwikkelen en testen van een computerprogramma binnen de software engineering voornamelijk afhankelijk is van de mate van communicatie binnen de ontwikkelgroep voor het programma. Specifiek moet er intensieve communicatie plaatsvinden tussen alle verschillende actoren binnen een softwareproject, ongeacht hun rol.
Een groot probleem hierbij is echter dat er een aantal verschillende rollen zijn binnen ieder softwareproject, die allemaal anders tegen het project aankijken. De FIT-groep spreekt in principe van drie rollen (de klanten, de testers en de programmeurs). Al deze rollen hebben hun eigen kijk op het project en een eigen belang bij het succesvol afronden van het project. Maar omdat ze allemaal een eigen kijk hebben op het leven en het project, is het moeilijk om een diepgaande communicatie tot stand te brengen tussen actoren met een verschillende rol. Een "klant" bijvoorbeeld heeft een functionele kijk op het project, weet waar het project past in het zakelijke landschap, wat er functioneel van het op te leveren programma verwacht wordt. Een "programmeur" daarentegen kijkt er op een technische manier tegenaan, weet hoe de software gebouwd wordt, welke bibliotheken gebruikt worden, enzovoorts.
FIT is bedoeld als softwaretool om communicatie tussen al deze rollen tot stand te brengen.
Theorie bewerken
De theorie achter FIT borduurt voort op de theorie achter domein-gestuurd ontwerp, zoals beschreven in Domain-Driven Design van Eric Evans. Een van de belangrijkste ideeën die gepresenteerd worden in dat boek is dat een softwareproject alleen kans van slagen heeft als er vloeiende communicatie is tussen alle belanghebbenden (en:stakeholders) bij het project. De belanghebbenden worden in hun communicatie echter gehinderd door het feit dat zij allemaal vanuit een eigen perspectief tegen het project aankijken en een eigen soort belang bij het project hebben; ze spelen allemaal een eigen rol bij het project. Dientengevolge spreekt iedere belanghebbende ook een eigen taal, een eigen jargon dat is toegesneden op zijn perspectief op het project.
Domein-gestuurd ontwerpen is gebaseerd op het idee dat belanghebbenden in iedere rol in het project samen moeten komen tot een gemeenschappelijke taal waarin ze kunnen spreken over het project. Door het opzetten van een gemeenschappelijke taal kunnen alle actoren (medewerkers) in het project samen spreken over het project op een manier die iedereen begrijpt en ook voor zich kan doorvertalen naar het eigen jargon om te zien of wat er gezegd wordt ook echt klopt.
FIT is een versimpelde uitvoering van dit proces, gespecialiseerd op het opbouwen en testen van de op te leveren software (domein-gestuurd ontwerpen heeft ook een weerslag buiten de software en beïnvloedt de hele projectstructuur, het projectmanagement, enzovoorts). FIT forceert een gemeenschappelijke taal die belanghebbenden van iedere rol kunnen gebruiken om samen te bepalen wanneer de software naar behoren werkt en wanneer niet.
Rollen bewerken
De bedenkers van FIT onderscheiden zelf drie rollen (klant, tester en programmeur) die van belang zijn voor de op te leveren software.
Klant bewerken
De klant is sturend voor het project. De klant is er de reden van dat het project gestart is, de klant is degene die het project bekostigt (en die dus verwachtingen uit mag spreken ten aanzien van de software) en de klant is ook nog eens degene die functioneel weet wat de software moet doen (dat wil zeggen: hij weet welke functies de eindgebruikers van de software zullen verwachten). En uiteraard heeft de klant ook kennis van de niet-functionele eisen die aan de software gesteld worden, zoals eisen aan "performance" (hoe de klant dat ook definieert), systeemomgeving, enzovoorts.
Tester bewerken
De tester is de rol binnen het project die verantwoordelijk is om erop toe te zien dat de opgeleverde software voldoet aan de eisen van de klant. De tester heeft daartoe zowel functioneel inzicht (hij is bekend met het probleemdomein van de software) als technisch inzicht (hij weet meer over het functioneren van de software, weet naast wat het doet ook hoe hij de software moet bedienen, of er praktische problemen of limieten aan de software zijn, et cetera). De tester is bijvoorbeeld in staat om de functionele eisen van de klant op te leveren; als de klant zegt "de software moet rente berekenen", dan kan de tester dat vertalen in "als ik er dit en dit getal in stop, moet er dit getal uitkomen".
Programmeur bewerken
De programmeur is degene die verantwoordelijk is voor het programmeren van de software aan de hand van een specificatie van de klant. De programmeur heeft voornamelijk technische kennis van de software: hij weet hoe de code gebouwd is, welke datastructuren er gebruikt zijn, welke API's er gebruikt zijn, dat soort dingen. De programmeur bouwt gaandeweg uiteraard enige functionele kennis op van de software, maar heeft over het algemeen geen overzicht over het hele systeem of hoe zijn software precies past in het geheel.
Gemeenschappelijke taal bewerken
FIT voert een gemeenschappelijke taal voor alle rollen en belanghebbenden in om te gebruiken bij het testen van software. Om dit mogelijk te maken en tegelijkertijd simpel te houden, beschouwt FIT een te testen stuk software als een black box waarbij het testteam alleen controle heeft over de in- en uitvoer van de software. Het FIT-raamwerk bestaat uit een redelijk simpel mechanisme waarmee de klant, de tester en de programmeur samen en interactief een batterij tests voor software kunnen opstellen en uitvoeren.
Een test van een stuk software in het FIT-raamwerk bestaat uit een tabel waarin de invoer voor een test is opgenomen en daarbij de verwachte uitvoer. Het raamwerk zelf bestaat uit software die de tabel inleest, de invoerwaarden eruit haalt en de te testen software afspeelt met die invoer. De eigenlijke uitvoer wordt dan vergeleken met de verwachte waarden uit de tabel. Ten slotte geeft het raamwerk de oorspronkelijke tabel opnieuw weer, aangevuld met enige kleurcodering: als de verwachte waarde overeenkomt met het echte resultaat wordt de verwachte waarde in het groen weergegeven, anders in het rood. Het achterliggende idee is dat de taal van in- en uitvoerparen en groen of rood simpel genoeg is dat actoren in iedere rol die taal kunnen volgen en spreken.
Een belangrijk onderdeel van het FIT-raamwerk is de mogelijkheid voor alle rollen om snel tests op te kunnen stellen, uit te kunnen voeren, aan te kunnen passen of in te kunnen zien. Dat vereist software dat het makkelijk maakt voor alle soorten actoren om tabellen op te stellen en te wijzigen en ook om de tests uit te voeren. Dat zijn zwaardere eisen dan in eerste instantie lijkt; bedenk maar eens dat de meeste mensen het al moeilijk vinden om in HTML een tabel op te bouwen. Daarnaast moet het natuurlijk ook niet alleen mogelijk zijn om test op te stellen en te wijzigen, een nuttig tool moet ook veranderingen terug kunnen draaien (want fouten komen zeker voor). Opgestelde tests moeten opgeslagen kunnen worden en makkelijk teruggevonden kunnen worden (een tool waarin je 150 testtabellen inklopt die weg zijn als je de computer uitzet, wordt gewoon niet gebruikt). Het liefst moet het mogelijk zijn om tests te kopiëren, om andere tests te maken die lijken op de gekopieerde tests. En ook de mogelijkheid om toelichtende tekst toe te voegen aan de testtabel is zeker wenselijk. En ook het testen zelf moet makkelijk zijn: het moet net zo makkelijk zijn om een batterij van 1000 tests uit te voeren als het is om een enkele test uit te voeren. Of een selectie uit die 1000 tests.
Gebruiksgemak bewerken
Het zal duidelijk zijn dat gebruiksgemak bij FIT de eerste prioriteit heeft: het bewerkings- en testtool moet laagdrempelig zijn en de gebruiker in alles ondersteunen. Het FIT-team van Object Mentor raadt makers van FIT-implementaties aan om als bewerkingstool een wikitool te gebruiken en dat om te bouwen zodat de tests direct vanuit de Wiki uitgevoerd kunnen worden.
Het framework bewerken
Het FIT-raamwerk is van zichzelf niet een uitvoerbaar stuk software. Het raamwerk bestaat voornamelijk uit documentatie en standaarden.
Het voornaamste onderdeel van het raamwerk is de documentatie aangaande het gebruik en de toepassing van FIT. Deze documentatie is gratis verkrijgbaar op de FIT website. Daarnaast is er het boek van Ward Cunningham en Rick Mugridge.
Voor mensen die implementaties van FIT willen bouwen, bevat de documentatie aanwijzingen voor de functionaliteit van het bewerkingstool en een specificatie van het soort testtabellen dat ondersteund hoort te worden. Qua bewerkingssoftware wordt een wiki aangeraden, maar een ander tool dat soortgelijke functionaliteit biedt kan ook. Er wordt een beschrijving gegeven van het gebruik van een tekstverwerker en de ingebouwde scripttaal.
Tests en tabellen bewerken
Het raamwerk definieert drie soorten tests en bijbehorende tabellen. Deze types worden aangeduid met het bijbehorende type fixture.
Kolomtest (ColumnFixture) bewerken
In deze testsoort bevat de tabel in iedere rij van de tabel een aparte test. Iedere kolom van de tabel kan invoer zijn voor een test of verwachte uitvoer.
Rijentest (RowFixture) bewerken
In deze testsoort is er geen invoer. Elke rij is een apart stuk uitvoer, bestaande uit een aantal velden (iedere kolom is een veld). Dit type test is bedoeld voor het testen van het type software dat grote hoeveelheden data oplevert, zoals database query's.
Actietest (ActionFixture) bewerken
Deze testsoort bestaat om processen te testen (het uitvoeren van een aantal acties door het programma, de werking van een GUI, dat soort dingen). Een proces wordt voorgesteld als een machine met knoppen en een interne toestand. Iedere rij bevat een commandokolom met daarin een commando ("duw op deze knop") en een kolom die het effect beschrijft. De hele tabel is een soort beschrijving van een eindige toestandsautomaat, zodat allerlei simpele processen beschreven kunnen worden. Het geheel wordt in de documentatie vergeleken met de werking van een rekenmachine met knoppen en een display dat uitgelezen wordt.
Fixtures bewerken
Een belangrijke positie bij het gebruik van FIT is weggelegd voor de programmeur. Voor iedere test die opgesteld wordt, moet namelijk code geschreven worden om de tabel te verbinden met de te testen software. Hoewel implementaties van het raamwerk wel software leveren die de testtabellen uitleest, moeten de uitgelezen waarden nog wel aan de te testen software gevoerd worden op een manier die die software begrijpt. En uiteraard moet de uitvoer van de software klaargezet worden voor de FIT software in een vorm die de FIT software begrijpt.
De brug die een Programmeur schrijft tussen tabel en te testen software, wordt een fixture genoemd. Van een raamwerkimplementatie wordt verwacht dat deze het de Programmeur makkelijk maakt om een fixture te schrijven; dat betekent dat een raamwerkimplementatie iedere testsoort moet ondersteunen met een basisfixture die het grootste gedeelte van de benodigde functionaliteit biedt. De bedoeling is dat een Programmeur een fixture kan bouwen door een paar simpele uitbreidingen te schrijven op een basisfixture. En die uitbreidingen moeten het liefst zo simpel mogelijk zijn: niet alleen omdat het gebruik van FIT voor de programmeur anders te veel werk wordt, maar ook omdat complexiteit in de fixtures de kans op fouten verhoogt. En dat in software die eigenlijk bedoeld is om fouten mee op te sporen.
Implementaties bewerken
Er zijn een aantal verschillende implementaties van het FIT-raamwerk beschikbaar, voornamelijk gespecialiseerd naar programmeertaal. Ten tijde van dit schrijven zijn de volgende implementaties bekend:
- FitLibrary Een simpele implementatie die zich vooral richt op fixturetypen en minder op de bewerkingssoftware. Implementeert alle standaardfixtures en voegt daar een aantal fixtures aan toe. Maakt het ook mogelijk om eigen fixtures als plugins toe te voegen. Bevat implementaties voor onder meer Java, C# en C++.
- FitNesse Een uitgebreide implementatie van FIT. Gebruikt FitLibrary en zet daar een zelfgebouwde Wiki tegenaan. FitNesse is gericht op Java, maar er wordt hard gewerkt aan de eerste, definitieve versie van een port naar C#. De bedoeling is dat C++ en Python ook implementaties krijgen.
- WinFitRunnerLite Een kleine implementatie van Microsoft, die gebruikmaakt van een kleine bibliotheek en Excel als voorkant.
Bronnen, noten en/of referenties
|