Wat is Test Driven Development (TDD)? Voorbeeld
Wat is Test Driven Development (TDD)?
Testgestuurde ontwikkeling (TDD) is een softwareontwikkelingsaanpak waarbij testgevallen worden ontwikkeld om te specificeren en te valideren wat de code zal doen. In eenvoudige bewoordingen worden voor elke functionaliteit eerst testgevallen gemaakt en getest. Als de test mislukt, wordt de nieuwe code geschreven om de test te doorstaan en de code eenvoudig en foutvrij te maken.
Test-Driven Development begint met het ontwerpen en ontwikkelen van tests voor elke kleine functionaliteit van een applicatie. Het TDD-framework instrueert ontwikkelaars om alleen nieuwe code te schrijven als een geautomatiseerde test is mislukt. Dit voorkomt duplicatie van code. De volledige vorm van TDD is testgestuurde ontwikkeling.
Het eenvoudige concept van TDD is om de mislukte tests te schrijven en te corrigeren voordat nieuwe code wordt geschreven (vóór de ontwikkeling). Dit helpt duplicatie van code te voorkomen, omdat we een kleine hoeveelheid code tegelijk schrijven om tests te doorstaan. (Tests zijn niets anders dan vereiste voorwaarden die we moeten testen om eraan te voldoen).
Testgestuurde ontwikkeling is een proces waarbij geautomatiseerde tests worden ontwikkeld en uitgevoerd voordat de applicatie daadwerkelijk wordt ontwikkeld. Daarom wordt TDD soms ook wel as genoemd Test de eerste ontwikkeling.
Hoe u een TDD-test uitvoert
De volgende stappen definiëren hoe u een TDD-test uitvoert:
- Voeg een toets toe.
- Voer alle tests uit en kijk of een nieuwe test mislukt.
- Schrijf wat code.
- Voer tests en Refactor-code uit.
- Herhaling.
TDD-cyclus definieert
- Schrijf een test
- Laat het rennen.
- Verander de code om deze goed te maken, bijvoorbeeld Refactor.
- Herhaal proces.
Enkele verduidelijkingen over TDD:
- De TDD-aanpak gaat niet over “testen” en ook niet over “ontwerpen”.
- TDD betekent niet “schrijf enkele tests en bouw vervolgens een systeem dat de tests doorstaat.
- TDD betekent niet ‘veel testen’.
TDD versus. Traditioneel testen
Hieronder ziet u het belangrijkste verschil tussen testgestuurde ontwikkeling en traditioneel testen:
De TDD-benadering is voornamelijk een specificatietechniek. Het zorgt ervoor dat uw broncode grondig wordt getest op bevestigingsniveau.
- Bij traditioneel testen worden bij een succesvolle test één of meerdere gebreken gevonden. Het is hetzelfde als TDD. Wanneer een toets mislukt, heb je vooruitgang geboekt omdat je weet dat je het probleem moet oplossen.
- TDD zorgt ervoor dat uw systeem ook daadwerkelijk voldoet aan de eisen die daaraan gesteld worden. Het helpt om uw vertrouwen in uw systeem op te bouwen.
- Bij TDD ligt de nadruk meer op productiecode die verifieert of het testen goed zal werken. Bij traditioneel testen ligt de nadruk meer op het ontwerpen van testgevallen. Of de test de juiste/onjuiste uitvoering van de applicatie zal aantonen om aan de vereisten te voldoen.
- Bij TDD behaalt u een dekkingstest van 100%. Elke regel code wordt getest, in tegenstelling tot traditioneel testen.
- De combinatie van zowel traditioneel testen als TDD leidt tot het belang van het testen van het systeem in plaats van het perfectioneren van het systeem.
- In Agile modelleren (AM), moet je “testen met een doel”. Je moet weten waarom je iets test en op welk niveau het getest moet worden.
Wat is acceptatie TDD en ontwikkelaar TDD
Er zijn twee niveaus van TDD
- Acceptatie TDD (ATDD): Met ATDD schrijft u één acceptatietest. Deze test voldoet aan de eis van de specificatie of voldoet aan het gedrag van het systeem. Schrijf daarna net genoeg productie-/functionaliteitscode om aan die acceptatietest te voldoen. Acceptatietest richt zich op het algehele gedrag van het systeem. ATDD stond ook bekend als Gedragsgestuurde ontwikkeling (BDD).
- Ontwikkelaar TDD: Met Developer TDD schrijf je een enkele ontwikkelaarstest, dat wil zeggen een unit-test, en vervolgens net genoeg productiecode om die test te voltooien. De unittest richt zich op elke kleine functionaliteit van het systeem. Ontwikkelaar TDD wordt simpelweg genoemd als TDD.Het belangrijkste doel van ATDD en TDD is het specificeren van gedetailleerde, uitvoerbare vereisten voor uw oplossing op een just in time (JIT) basis. JIT betekent dat alleen die vereisten in overweging worden genomen die nodig zijn in het systeem. Verhoog dus de efficiëntie.
TDD opschalen via Agile Model Driven Development (AMDD)
TDD is erg goed in gedetailleerde specificatie en validatie. Het slaagt er niet in om grotere kwesties zoals het algehele ontwerp, het gebruik van het systeem of de gebruikersinterface te doordenken. AMDD pakt de Agile-schalingsproblemen aan die TDD niet aanpakt.
Zo werd AMDD gebruikt voor grotere problemen.
De levenscyclus van AMDD
Bij Model-driven Development (MDD) worden uitgebreide modellen gemaakt voordat de broncode wordt geschreven. Welke hebben op hun beurt een agile aanpak?
In de bovenstaande afbeelding vertegenwoordigt elk vakje een ontwikkelingsactiviteit.
Envisioning is een van de TDD-processen van het voorspellen/verbeelden van tests die worden uitgevoerd tijdens de eerste week van het project. Het hoofddoel van envisioning is het identificeren van de scope van het systeem en de architectuur van het systeem. High-level requirements en architectuurmodellering worden gedaan voor succesvolle envisioning.
Het is het proces waarbij geen gedetailleerde specificatie van software/systeem wordt gedaan, maar waarbij de vereisten van software/systeem worden onderzocht, dat de algemene strategie van het project definieert.
Iteratie 0: visualiseren
Er zijn twee belangrijke sub-activa.
- Initiële vereisten in beeld.Het kan enkele dagen duren om de vereisten op hoog niveau en de reikwijdte van het systeem te identificeren. De belangrijkste focus ligt op het verkennen van het gebruiksmodel, het initiële domeinmodel en het gebruikersinterfacemodel (UI).
- Eerste Architecturale visie. Het duurt ook meerdere dagen om de architectuur van het systeem te identificeren. Het maakt het mogelijk om technische richtingen voor het project vast te stellen. De belangrijkste focus ligt op het verkennen van technologiediagrammen, User Interface (UI)-flow, domeinmodellen en Change cases.
Iteratiemodellering
Hier moet het team het werk plannen dat voor elke iteratie zal worden gedaan.
- Voor elke iteratie wordt een Agile proces gebruikt, dat wil zeggen dat tijdens elke iteratie een nieuw werkitem met prioriteit wordt toegevoegd.
- Eerst zullen werkzaamheden met een hogere prioriteit in overweging worden genomen. Toegevoegde werkitems kunnen op elk gewenst moment een nieuwe prioriteit krijgen of van de stapel met items worden verwijderd.
- Het team bespreekt hoe ze elke eis gaan implementeren. Hiervoor wordt gebruik gemaakt van modellering.
- Modelanalyse en ontwerp worden uitgevoerd voor elke vereiste die voor die iteratie wordt geïmplementeerd.
Modelbestorming
Dit wordt ook wel Just-in-time-modellering genoemd.
- Bij deze modelleringssessie is een team van 2/3 leden betrokken die problemen op papier of op een whiteboard bespreken.
- Het ene teamlid vraagt een ander om samen met hem model te staan. Deze modelleersessie duurt ongeveer 5 tot 10 minuten. Waar teamleden samenkomen om whiteboard/papier te delen.
- Ze onderzoeken problemen totdat ze de hoofdoorzaak van het probleem niet kunnen vinden. Als een teamlid, net op tijd, het probleem identificeert dat hij/zij wil oplossen, zal hij/zij snel de hulp van andere teamleden inroepen.
- Andere groepsleden onderzoeken het probleem vervolgens en iedereen gaat verder zoals voorheen. Het wordt ook wel stand-up modellering of QA-sessies voor klanten genoemd.
Testgestuurde ontwikkeling (TDD)
- Het bevordert het bevestigend testen van uw applicatiecode en gedetailleerde specificaties.
- Zowel acceptatietest (gedetailleerde eisen) als ontwikkelaarstests (unittest) zijn input voor TDD.
- TDD maakt de code eenvoudiger en duidelijker. Hierdoor hoeft de ontwikkelaar minder documentatie bij te houden.
Recensies
- Dit is optioneel. Het omvat code-inspecties en modelbeoordelingen.
- Dit kan voor elke iteratie of voor het hele project.
- Dit is een goede mogelijkheid om feedback te geven op het project.
Testgestuurde ontwikkeling (TDD) versus. Agile modelgedreven ontwikkeling (AMDD)
TDD | AMDD |
---|---|
TDD verkort de programmeerfeedbacklus | AMDD verkort de feedbacklus voor modellering. |
TDD is een gedetailleerde specificatie | AMDD werkt voor grotere problemen |
TDD bevordert de ontwikkeling van hoogwaardige code | AMDD bevordert hoogwaardige communicatie met belanghebbenden en ontwikkelaars. |
TDD spreekt met programmeurs | AMDD praat met Bedrijfsanalist, belanghebbenden en dataprofessionals. |
TDD niet-visueel georiënteerd | AMDD visueel georiënteerd |
TDD heeft een beperkte reikwijdte voor softwarewerken | AMDD heeft een brede reikwijdte, inclusief belanghebbenden. Het gaat om het werken aan een gemeenschappelijk begrip |
Beide ondersteunen de evolutionaire ontwikkeling | --------------- |
TDD-frameworks
Hier is de lijst met de beste testgestuurde ontwikkelingsframeworks (TDD).
Laten we nu Test Driven Development als voorbeeld leren.
Voorbeeld van TDD
Hier in dit Test Driven Development voorbeeld, zullen we een class wachtwoord definiëren. Voor deze class, zullen we proberen om te voldoen aan de volgende voorwaarden.
Een voorwaarde voor acceptatie van het wachtwoord:
- Het wachtwoord moet tussen de 5 en 10 tekens lang zijn.
In dit TDD-voorbeeld schrijven we eerst de code die aan alle bovenstaande vereisten voldoet.
Scenario 1: Om de test uit te voeren, maken we de klasse PasswordValidator ();
We zullen boven de klasse TestPassword ();
De uitvoer is GESLAAGD, zoals hieronder weergegeven;
uitgang:
Scenario 2: Hier kunnen we zien dat in de methode TestPasswordLength () het niet nodig is om een exemplaar van de klasse PasswordValidator te maken. Instance betekent het creëren van een object van klasse om naar de leden (variabelen/methoden) van die klasse te verwijzen.
We zullen de klasse WachtwoordValidator pv = new WachtwoordValidator () uit de code verwijderen. Wij kunnen bellen met de is geldig () methode direct door WachtwoordValidator. Is geldig (“Abc123”). (Zie afbeelding hieronder)
Dus we Refactor (code wijzigen) zoals hieronder:
Scenario 3: Na het refactoren toont de uitvoer de status Mislukt (zie onderstaande afbeelding). Dit komt omdat we de instantie hebben verwijderd. Er is dus geen verwijzing naar niet-statisch methode is geldig ().
We moeten deze methode dus wijzigen door een “statisch” woord vóór Boolean toe te voegen, aangezien de openbare statische Boolean Geldig is (String-wachtwoord). Refactoring Class PasswordValidator () om bovenstaande fout te verwijderen en de test te doorstaan.
Output:
Nadat we wijzigingen hebben aangebracht in de klasse PassValidator () als we de test uitvoeren, wordt de uitvoer GESLAAGD, zoals hieronder weergegeven.
Voordelen van TDD
Hieronder staan de belangrijkste voordelen van Test Driven Development in software engineering:
Vroege bugmelding.
- Ontwikkelaars testen hun code, maar in de databasewereld bestaat dit vaak uit handmatige tests of eenmalige scripts. Met behulp van TDD bouwt u in de loop van de tijd een reeks geautomatiseerde tests op die u en elke andere ontwikkelaar naar believen kunnen herhalen.
Beter ontworpen, schonere en beter uitbreidbare code.
- Het helpt om te begrijpen hoe de code zal worden gebruikt en hoe deze samenwerkt met andere modules.
- Het resulteert in betere ontwerpbeslissingen en beter onderhoudbare code.
- TDD maakt het schrijven van kleinere code met één enkele verantwoordelijkheid mogelijk in plaats van monolithische procedures met meerdere verantwoordelijkheden. Dit maakt de code eenvoudiger te begrijpen.
- TDD dwingt ook om alleen productiecode te schrijven om tests te doorstaan op basis van gebruikersvereisten.
Vertrouwen in Refactor
- Als u code refactoreert, kunnen er breuken in de code optreden. Met een reeks geautomatiseerde tests kunt u deze onderbrekingen oplossen voordat u deze uitbrengt. Er wordt een juiste waarschuwing gegeven als er pauzes worden gevonden bij het gebruik van geautomatiseerde tests.
- Het gebruik van TDD zou moeten resulteren in snellere, beter uitbreidbare code met minder bugs die met minimale risico's kan worden bijgewerkt.
Goed voor teamwerk
- Bij afwezigheid van een teamlid kunnen andere teamleden de code gemakkelijk oppakken en eraan werken. Het bevordert ook het delen van kennis, waardoor het team in het algemeen effectiever wordt.
Goed voor ontwikkelaars
- Hoewel ontwikkelaars meer tijd moeten besteden aan het schrijven van TDD-testcases, kost het veel minder tijd aan het debuggen en ontwikkelen van nieuwe functies. Je schrijft schonere, minder gecompliceerde code.
Samenvatting
- TDD staat voor Testgedreven Ontwikkelen.
- TDD betekent: het is een proces waarbij de code wordt aangepast om een eerder ontworpen test te doorstaan.
- Er wordt meer nadruk gelegd op productiecode dan op testcase-ontwerp.
- Testgestuurde ontwikkeling is een proces waarbij de code wordt aangepast om een eerder ontworpen test te doorstaan.
- In Software Engineering, Het is ook wel bekend als “Test eerste ontwikkeling.”
- TDD-testen omvatten het refactoren van een code, dat wil zeggen het wijzigen/toevoegen van een bepaalde hoeveelheid code aan de bestaande code zonder het gedrag van de code te beïnvloeden.
- Bij gebruik van TDD-programmering wordt de code duidelijker en eenvoudiger te begrijpen.