Share
Het kernidee van Test-Driven Development (TDD) is het schrijven van tests voordat een functionele code wordt geschreven en vervolgens alleen de kleinst mogelijke hoeveelheid code wordt geschreven die nodig is om de tests te laten slagen. Het klinkt misschien vreemd om op deze manier te ontwikkelen, maar het is eigenlijk best nuttig, omdat de testbank ook fungeert als een gedeeltelijke specificatie van de hoofdcode..
Gezien een dergelijk eenvoudig uitgangspunt is er echter een verbazingwekkende hoeveelheid terminologie en technieken. In dit artikel verzamel ik de belangrijkste termen en modewoorden die u mogelijk hoort, en definieer deze.
Test-first programming maakt functionele tests op hoog niveau mogelijk.
Het hoogste niveau van testen valideert dat de software voldoet aan de eisen van de klant. Acceptatietests worden meestal uitgevoerd in omgevingen die zo dicht mogelijk bij de productie liggen. Zie functionele testen en systeemtesten.
Assertions zijn statements die een daadwerkelijke controle uitvoeren op de output van de software. Over het algemeen wordt een enkele functie genoemd beweren is voldoende om elke cheque uit te drukken. In de praktijk hebben testbibliotheken vaak veel assert-functies om aan specifieke behoeften te voldoen (zoals assertFalse, assertEqual en meer) om een betere analyse en vriendelijkere output te bieden.
Een testtechniek die de test verdubbelt in de software, beweert dat hij de correcte methoden in een juiste volgorde noemt. Zie mock voor een voorbeeld. Zie ook staat testen.
Een subset van TDD, aangedreven door de behoefte aan duidelijkere communicatie en goede documentatie. BDD is misschien wel de grootste recente ontwikkeling in TDD.
De kerngedachte is om verwarrende en op ontwikkelaars gerichte terminologie te vervangen (testen, suites, beweringen enz.) met alomtegenwoordige taal dat alle deelnemende belanghebbenden (inclusief niet-technisch personeel en mogelijk klanten) het kunnen begrijpen.
Zie gebruikersverhaal.
Een algemeen principe bij het testen waarbij de persoon die tests schrijft, de internalen van de software niet kent of vermijdt, en in plaats daarvan de openbare interface van de software strikt aan de interface of specificatie ervan test. Zie white-box testen.
Een strategie voor het schrijven van tests om off-by-one en andere soortgelijke soorten fouten op te vangen. Om grenswaardetests uit te voeren, test u de inputs rond bepaalde mogelijk problematische grenzen. In het geval van gehele getallen, kan dit zijn 0, -1, MIN_INT, MAX_INT en andere soortgelijke waarden.
Assertions zijn statements die een daadwerkelijke controle uitvoeren op de output van de software.
Een dummy is een type testdubbel dat nooit door de eigenlijke software wordt gebruikt, maar alleen in de test wordt gebruikt om de vereiste parameters in te vullen.
Fakes zijn testdubbels die de vereiste functionaliteit implementeren op een manier die nuttig is bij het testen, maar die ook effectief diskwalificeert om niet in de productieomgeving te worden gebruikt. Een database met sleutelwaarden die alle waarden in het geheugen opslaat en verliest ze na elke uitvoering, maakt het mogelijk dat tests sneller worden uitgevoerd, maar de neiging om gegevens te vernietigen maakt het niet mogelijk om in de productie te worden gebruikt.
Een specifieke omgeving die moet worden ingesteld voordat een test kan worden uitgevoerd. Het bestaat over het algemeen uit het instellen van alle testdubbelen en andere afhankelijkheden voor de geteste software: zoals het invoegen van vooraf gedefinieerde gegevens in een valse database, het instellen van een bepaalde directorystructuur in het nepbestandssysteem, het instellen van eigenschappen op de afhankelijkheden van de geteste software.
Een testactiviteit op hoog niveau die controleert of aan alle zakelijke vereisten van het product is voldaan. Functioneel testen omvat meestal het gebruik van gebruikersverhalen om zich te concentreren op een hoger niveau van eisen om zo veel mogelijk gebruiksscenario's te dekken. Zie acceptatietesten en systeemtesten. Bijvoorbeeld:
# In dit voorbeeld controleren we dat de betreffende pagina van de website werkt zoals verwacht open 'example.com' clickOn 'over ons' assertThereIs 'Wij zijn een klein voorbeeldbedrijf'
Een spreektaal voor een passerende verzameling testen, of soms een bepaalde slaagtest. Zie rood.
Een testactiviteit op gemiddeld niveau die een bepaald aantal modules controleert, werkt correct samen. Integratietests zijn vergelijkbaar met unit-tests zonder test-doubles te gebruiken voor een bepaalde subset van afhankelijkheden, waarbij in essentie de interacties tussen de software en de afhankelijkheden ervan worden getest. Voorbeeld:
Accentsconagua
# In dit voorbeeld controleren we of de nieuw geregistreerde gebruiker, # die door een andere gebruiker is verwezen, een on-site "vriendschap" heeft aangemaakt. # Hier controleren we de interactie tussen de formulier-controller, # database en een actieve record van de gebruiker db = new Fake Db u1 = db.createUser (name = 'john') RegistrationForm (db, name = "kate", references = "john ") .save () assert (u1.hasFriend ('kate')) Een type testdubbel gemaakt voor een specifieke test of testcase. Het verwacht een specifiek aantal keren te worden genoemd en geeft een vooraf gedefinieerd antwoord. Aan het einde van de test roept een mock een fout op als deze niet zo vaak wordt genoemd als verwacht. Een spot met strikte verwachtingen maakt deel uit van het assertiekader. Voorbeeld:
# In dit voorbeeld gebruiken we een nepdatabase om te controleren of het formulier # de database gebruikt om de nieuwe gebruiker op te slaan. # Als de database aan het einde van de test niet is aangeroepen, # zal de mock zelf een assertiefout veroorzaken. db = nieuwe Mock Db db.expect ('save'). once (). with (name = 'john') RegistrationForm (db, name = "john"). save () Een manier om het gedrag van bestaande objecten en klassen in een programmeertaal uit te breiden en te veranderen. Monkey-patching kan worden gebruikt als een alternatief voor afhankelijkheidsinjectie en test doubles door bestaande functies die worden aangeroepen door de geteste software direct te wijzigen (en deze na de test te wijzigen).
# In dit voorbeeld vervangen we de standaard bibliotheekfunctie # om te voorkomen dat de test een echt bestandssysteembestandssysteem gebruikt.listdir = f (naam) -> ['.', '...', 'foo', 'bar']; assertEqual (MyFileSearch ('foo'). count (), 1) Een spreektaal voor een falende verzameling tests of soms een specifieke test. Zie groen.
Het proces om implementatiedetails van code te verbeteren zonder de functionaliteit ervan te veranderen.
Refactoring zonder tests is een zeer broos proces, omdat de ontwikkelaar die de refactoring uitvoert er nooit zeker van kan zijn dat zijn verbeteringen sommige delen van de functionaliteit niet doorbreken.
Als de code is geschreven met behulp van testgestuurde ontwikkeling, kan de ontwikkelaar er zeker van zijn dat zijn refactoring succesvol was zodra alle tests zijn geslaagd, omdat alle vereiste functionaliteit van de code nog steeds correct is.
Een softwarefout dat na een bepaalde gebeurtenis in een bepaalde functie verschijnt (meestal een wijziging in de code).
Scenario testen
Zie functionele testen.
Een proces van het voorbereiden van een armatuur. Zie demontage. Voorbeeld:
# In dit voorbeeld maken we een nep-database met enkele nep-waarden # die we nodig hebben voor meerdere tests db = new Fake Db db.createUser (name = 'john') db.createUser (name = 'kate') db.createFriendship ( 'john', 'kate')
Een vorm van eenheidscontrole wanneer de testcode de test oplevert, verdubbelt naar en stelt dat de toestand van deze doubles op correcte wijze is gewijzigd. Zie gedragstesten.
# In dit voorbeeld, zoals in een voorbeeld van schijnobjecten, # controleren we of het formulier de database gebruikt om de nieuwe gebruiker op te slaan. # Deze keer controleren we de staat, in plaats van het gedrag db = new Fake Db RegistrationForm (db, name = "john"). Save () assertInList ('john', db.listUsers ()) Fakes zijn testdubbels die nooit door de eigenlijke software worden gebruikt.
Een type testdubbel dat kan antwoorden op de software die wordt getest met vooraf gedefinieerde antwoorden. In tegenstelling tot moppen controleren stubs meestal niet of ze correct zijn gecrawld, maar zorgen ze er alleen voor dat de software zijn afhankelijkheden kan aanroepen..
Een testactiviteit op hoog niveau wanneer de volledige software van boven naar beneden wordt getest. Dit omvat functionele testen, evenals het controleren van andere kenmerken (zoals prestaties en stabiliteit).
Een afkorting voor software die getest wordt. Wordt gebruikt om de geteste software te onderscheiden van de afhankelijkheden.
Een proces om een armatuur schoon te maken. In talen die in vuilnis worden verzameld, wordt deze functionaliteit meestal automatisch afgehandeld. Zie setup.
De kleinst mogelijke controle op juistheid. Een enkele test voor een webformulier kan bijvoorbeeld een controle zijn dat het formulier bij een ongeldig e-mailadres de gebruiker waarschuwt en een oplossing voorstelt. Zie testcase.
Een verzameling tests gegroepeerd op basis van een kenmerk. Een testcase voor een webformulier kan bijvoorbeeld een verzameling tests zijn die het gedrag van het formulier controleren op verschillende geldige en ongeldige invoer.
functie t1: assertNoError (RegistrationForm (name = 'john', wachtwoord = "paardenbatterij niet correct"). save ()) functie t2: assertError (MissingPassword, RegistrationForm (name = 'john'). save ()) functie t3: assertError (StupidPassword, RegistrationForm (name = 'john', password = "password"). save ())
Gebruikersverhalen worden meestal in menselijke talen gedefinieerd om in plaats daarvan te focussen op gebruikerservaring.
Elke soort metriek die poogt de waarschijnlijkheid van belangrijk gedrag van de SUT te schatten dat nog niet door tests wordt gedekt. De populairste technieken omvatten verschillende soorten code dekking: technieken die ervoor zorgen dat alle mogelijke codeverklaringen (of functies, of logische vertakkingen in de code) tijdens het testen zijn uitgevoerd.
Een proces van TDD-ontwikkeling. Aangezien TDD-ontwikkeling begint met het schrijven van enkele tests, is het duidelijk dat de testsuite rood begint te worden. Zodra de ontwikkelaar alle nieuw geteste functies implementeert, worden tests groen. Nu kan de ontwikkelaar zijn implementatie veilig herdefiniëren zonder het risico van het introduceren van nieuwe bugs, omdat hij een testsuite heeft waarop hij kan vertrouwen. Nadat het refactoringproces is voltooid, kan de ontwikkelaar de cyclus opnieuw starten door meer tests te schrijven voor meer nieuwe functionaliteit. Dus, de rood-groen-refactorentestcyclus.
Test dubbel
Testdubbelen zijn objecten die de testcode maakt en worden doorgestuurd naar de SUT om echte afhankelijkheden te vervangen. Unittests moeten bijvoorbeeld erg snel zijn en alleen een bepaald stuk software testen.
Om deze redenen worden de afhankelijkheden, zoals een database of bibliotheken voor bestandsysteeminteractie, meestal vervangen door objecten die in het geheugen werken in plaats van te praten met een echte database of een bestandssysteem.
Er zijn vier hoofdcategorieën testdubbels: dummies, namaakgoederen, stompjes en moppen.
Een verzameling testcases die een groot deel van de software testen. Als alternatief alle testgevallen voor een bepaalde software.
White-box testen maakt een diepere analyse mogelijk van mogelijke problemen in de code.
Test-first programming is een iets bredere term voor testgestuurde ontwikkeling. Hoewel TDD een sterke koppeling tussen schrijftests (meestal unit tests) en het schrijven van de code bevordert, maakt test-eerst programmeren in plaats daarvan functionele tests op hoog niveau mogelijk. Het onderscheid in algemeen gebruik wordt echter zelden opgemerkt en twee termen worden gewoonlijk door elkaar gebruikt.
De laagste niveau testtechniek bestaande uit testcases voor de kleinst mogelijke codeereenheden. Een test met één eenheid controleert meestal slechts een bepaald klein gedrag, en een eenheidstestcase dekt gewoonlijk alle functionaliteit van een bepaalde enkele functie of klasse.
Een enkele beschrijving van een bepaalde groep mensen die een bepaalde taak willen uitvoeren met behulp van de SUT om een bepaald doel te bereiken. Gebruikersverhalen worden meestal gedefinieerd in menselijke talen, met behulp van eenvoudige, gebruikersgerichte termen om te voorkomen dat implementatiedetails worden overwogen en in plaats daarvan te worden gericht op gebruikerservaring. Bijvoorbeeld:
Als gebruiker wil ik mijn vrienden op deze website kunnen vinden aan de hand van mijn adresboek, in plaats van ze een voor een te zoeken, want dat scheelt me veel tijd.
White-box testen is een testtechniek waarbij een persoon die de test uitvoert op de hoogte is of kan lezen van de interne onderdelen van de SUT. In tegenstelling tot de meer gebruikelijke Black-Box-tests, kunnen tests met een witte doos een diepere analyse van mogelijke problemen in de code mogelijk maken.
Een bepaalde grenswaarde kan er bijvoorbeeld niet zo uitzien op basis van de specificatie van de software, maar het kan duidelijk zijn door de implementatie ervan.
Bovendien zijn alle testdekkingstechnieken gewoonlijk per definitie onderdeel van de white-box-tests.
