Test gedreven ontwikkeling
Test Driven Development (TDD) is een softwareontwikkelingsbenadering waarbij testcases worden ontwikkeld om te specificeren en valideren wat de code zal doen. In eenvoudige bewoordingen worden testcases voor elke functionaliteit eerst gemaakt en getest en 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. TDD 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 ontwikkeling). Dit helpt om 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 van het ontwikkelen en uitvoeren van geautomatiseerde tests voordat de applicatie daadwerkelijk wordt ontwikkeld. Vandaar dat TDD ook wel Test First Development wordt genoemd.
In deze tutorial leert u meer over-
- Hoe TDD-test uit te voeren
- TDD Vs. Traditioneel testen
- Wat is acceptatie TDD en Developer TDD
- TDD opschalen via Agile Model Driven Development (AMDD)
- Test Driven Development (TDD) Vs. Agile Model Driven Development (AMDD)
- Voorbeeld van TDD
- Voordelen van TDD
Hoe TDD-test uit te voeren
De volgende stappen bepalen hoe de TDD-test moet worden uitgevoerd,
- Voeg een test toe.
- Voer alle tests uit en kijk of een nieuwe test mislukt.
- Schrijf een code.
- Voer tests uit en voer de code opnieuw uit.
- Herhaling.
TDD-cyclus definieert
- Schrijf een test
- Laat het rennen.
- Verander de code om het goed te maken, dwz Refactor.
- Herhaal het proces.
Enkele verduidelijkingen over TDD:
- TDD gaat niet over "Testen" noch over "Design".
- TDD betekent niet "enkele tests schrijven en vervolgens een systeem bouwen dat de tests doorstaat".
- TDD betekent niet "veel testen".
TDD Vs. Traditioneel testen
TDD-benadering is in de eerste plaats een specificatietechniek. Het zorgt ervoor dat uw broncode grondig wordt getest op bevestigingsniveau.
- Bij traditioneel testen vindt een succesvolle test een of meer defecten. Het is hetzelfde als TDD. Als een test mislukt, hebt u vooruitgang geboekt omdat u weet dat u het probleem moet oplossen.
- TDD zorgt ervoor dat uw systeem daadwerkelijk voldoet aan de eisen die ervoor zijn gedefinieerd. Het helpt om uw vertrouwen in uw systeem op te bouwen.
- In TDD ligt meer focus op productiecode die verifieert of testen correct zal werken. Bij traditioneel testen ligt de nadruk meer op het ontwerpen van testcases. Of de test de juiste / onjuiste uitvoering van de applicatie zal aantonen om aan de vereisten te voldoen.
- In TDD behaalt u een 100% dekkingstest. Elke regel code wordt getest, in tegenstelling tot traditionele tests.
- 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 Modeling (AM) moet je "testen met een doel". U moet weten waarom u iets test en op welk niveau het moet worden getest.
Wat is acceptatie TDD en Developer TDD
Er zijn twee niveaus van TDD
- Acceptatie TDD (ATDD): Met ATDD schrijf je een enkele 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 die acceptatietest te doorstaan. Acceptatietest richt zich op het algemene gedrag van het systeem. ATDD stond ook bekend als Behavioral Driven Development (BDD).
- Ontwikkelaar TDD: Met Developer TDD schrijf je een enkele ontwikkelaarstest, dwz een eenheidstest, en dan net genoeg productiecode om die test te volbrengen. De unit-test richt zich op elke kleine functionaliteit van het systeem. Ontwikkelaar TDD wordt eenvoudigweg TDD genoemd.
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 kan niet nadenken over grotere kwesties zoals het algehele ontwerp, het gebruik van het systeem of de gebruikersinterface. AMDD pakt de Agile-schaalproblemen aan die TDD niet doet.
Dus AMDD werd gebruikt voor grotere problemen.
De levenscyclus van AMDD.
In Model-driven Development (MDD) worden uitgebreide modellen gemaakt voordat de broncode wordt geschreven. Welke hebben op hun beurt een agile aanpak?
In bovenstaande figuur stelt elke box een ontwikkelingsactiviteit voor.
Envisioning is een van de TDD-processen van het voorspellen / verbeelden van tests die tijdens de eerste week van het project zullen worden uitgevoerd. Het belangrijkste doel van visualiseren is om de reikwijdte van het systeem en de architectuur van het systeem te identificeren. Vereisten op hoog niveau en architectuurmodellering worden gedaan voor een succesvolle visualisatie.
Het is het proces waarbij geen gedetailleerde specificatie van software / systeem wordt gedaan, maar waarbij de vereisten van software / systeem worden onderzocht die de algemene strategie van het project bepalen.
- Iteratie 0: Envisioning
Er zijn twee hoofdsubactiveringen.
- Initiële vereisten voorzien.
Het kan enkele dagen duren om de vereisten op hoog niveau en de omvang van het systeem te identificeren. De belangrijkste focus is om het gebruiksmodel, het initiële domeinmodel en het gebruikersinterfacemodel (UI) te verkennen.
- Initiële architecturale voorstelling.
Het duurt ook enkele dagen om de architectuur van het systeem te identificeren. Het maakt het mogelijk om technische richtlijnen voor het project op te stellen. De belangrijkste focus is het verkennen van technologiediagrammen, User Interface (UI) -stroom, 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.
- Er zal rekening worden gehouden met het eerste werk met een hogere prioriteit. Toegevoegde werkitems kunnen op elk moment een nieuwe prioriteit krijgen of uit de itemsstapel worden verwijderd.
- Het team bespreekt hoe ze elke vereiste gaan implementeren. Hiervoor wordt modellering gebruikt.
- Modelleringanalyse en -ontwerp wordt gedaan voor elke vereiste die voor die iteratie wordt geïmplementeerd.
- Model bestorming:
Dit wordt ook wel Just in time Modeling genoemd.
- Bij deze modelleringssessie is een team van 2/3 leden betrokken die kwesties op papier of op een whiteboard bespreken.
- Het ene teamlid zal een ander vragen om met hen te modelleren. 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. Net op tijd, als een teamlid het probleem identificeert dat hij / zij wil oplossen, zal hij / zij snel de hulp inroepen van andere teamleden.
- Andere groepsleden onderzoeken vervolgens het probleem en dan gaat iedereen verder zoals voorheen. Het wordt ook wel stand-up modellering of QA-sessies voor klanten genoemd.
- Test Driven Development (TDD).
- Het bevordert het testen van uw applicatiecode en gedetailleerde specificatie.
- Zowel acceptatietest (gedetailleerde vereisten) als ontwikkelaarstests (unit-test) zijn input voor TDD.
- TDD maakt de code eenvoudiger en duidelijker. Het stelt de ontwikkelaar in staat om minder documentatie bij te houden.
- Beoordelingen.
- Dit is optioneel. Het omvat code-inspecties en modelrecensies.
- Dit kan voor elke iteratie of voor het hele project worden gedaan.
- Dit is een goede optie om feedback te geven op het project.
Test Driven Development (TDD) Vs. Agile Model Driven Development (AMDD)
| TDD | AMDD |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Voorbeeld van TDD
Hier in dit voorbeeld zullen we een klassenwachtwoord definiëren. Voor deze les proberen we aan de volgende voorwaarden te voldoen.
Een voorwaarde voor wachtwoordacceptatie:
- Het wachtwoord moet tussen de 5 en 10 tekens lang zijn.
Eerst schrijven we de code die aan alle bovenstaande vereisten voldoet.
Scenario 1 : Om de test uit te voeren, maken we de klasse PasswordValidator ();
We draaien boven de klasse TestPassword ();
De uitvoer is PASSED zoals hieronder getoond;
Uitgang :
Scenario 2 : Hier kunnen we zien in methode TestPasswordLength () dat het niet nodig is om een instantie van de klasse PasswordValidator te maken. Instance betekent het maken van een klasseobject om de leden (variabelen / methoden) van die klasse te verwijzen.
We zullen de klasse PasswordValidator pv = new PasswordValidator () uit de code verwijderen. We kunnen de methode isValid () rechtstreeks aanroepen door PasswordValidator. IsValid ("Abc123") . (Zie afbeelding hieronder)
Dus we refactoren (code wijzigen) zoals hieronder:
Scenario 3 : Na refactoring toont de uitvoer de status mislukt (zie onderstaande afbeelding). Dit komt omdat we de instantie hebben verwijderd. Er is dus geen verwijzing naar de niet-statische methode isValid ().
We moeten deze methode dus wijzigen door een "statisch" woord toe te voegen vóór Boolean als public static boolean isValid (String-wachtwoord). Refactoring Class PasswordValidator () om bovenstaande fout te verwijderen en de test te doorstaan.
Uitgang:
Na het aanbrengen van wijzigingen in klasse PassValidator () als we de test uitvoeren, wordt de uitvoer PASSED zoals hieronder weergegeven.
Voordelen van TDD
- Vroegtijdige melding van bugs.
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 opnieuw kunnen uitvoeren.
- Beter ontworpen, schonere en uitbreidbare code.
- Het helpt om te begrijpen hoe de code zal worden gebruikt en hoe deze interageert met andere modules.
- Het resulteert in een betere ontwerpbeslissing en beter onderhoudbare code.
- TDD maakt het mogelijk om kleinere code te schrijven met een enkele verantwoordelijkheid 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 tot refactor
- Als u code refactoreert, kunnen er mogelijkheden zijn voor onderbrekingen in de code. Met een reeks geautomatiseerde tests kunt u die pauzes oplossen voordat u ze vrijgeeft. Er wordt een juiste waarschuwing gegeven als er onderbrekingen worden gevonden tijdens 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 kunnen worden bijgewerkt.
- Goed voor teamwerk
Bij afwezigheid van een teamlid kunnen andere teamleden de code gemakkelijk ophalen en eraan werken. Het helpt ook bij 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 om fouten op te sporen en nieuwe functies te ontwikkelen. Je schrijft schonere, minder gecompliceerde code.
Overzicht:
- TDD staat voor Test-driven development. Het is een proces waarbij de code wordt gewijzigd om een eerder ontworpen test te doorstaan.
- Het legt meer de nadruk op productiecode dan op het ontwerp van een testcase.
- Testgestuurde ontwikkeling is een proces waarbij de code wordt aangepast om een eerder ontworpen test te doorstaan.
- In Software Engineering wordt het ook wel "Test First Development" genoemd.
- TDD omvat het herstructureren van een code, dwz het wijzigen / toevoegen van een hoeveelheid code aan de bestaande code zonder het gedrag van de code te beïnvloeden.
- Wanneer TDD wordt gebruikt, wordt de code duidelijker en eenvoudiger te begrijpen.
Dit artikel is bijgedragen door Kanchan Kulkarni