Waarom Test Driven Development (TDD) de beste manier is voor robuuste codering.

Schrijf eerst eenheidstests en schrijf vervolgens de code.

Image Credits: Pexels.com

Enkele jaren geleden, toen ik voor het eerst hoorde van 'Test Driven Development', was ik sceptisch.

Alleen al het idee van "eerst schrijfeenheidstests, dan schrijf de code" was wartaal voor mij.

Waarom zou het niet zijn? Eerst je unit-tests schrijven? Wie zou zoiets goofy doen?

Maar ik was toen al tien jaar een professionele programmeur en ik had dingen in de industrie zien komen en gaan. Ik wist beter dan alles uit de hand te laten, vooral als ontwikkelaars er zo over zaten.

Dus raadpleegde ik een vriend van mij die me een eenvoudig voorbeeld liet zien.

Dit basisvoorbeeld heeft een klasse LCL_SUM met een methode SUM. De verantwoordelijkheid van deze methode is om de getallen TOE TE VOEGEN. Het neemt een getal als importparameter en voegt het vervolgens aan zichzelf toe om het resultaat af te leiden. Laten we deze methode een productiemethode noemen.

De code voor de klas was als volgt:

KLASSE lcl_sum DEFINITIE.
OPENBARE SECTIE.
METHODEN: SOM INVOER iv_1 TYPE i
RETOURZENDING (rv_sum) TYPE i.
ENDCLASS. “Lcl_sum DEFINITIE
*
START-OF-SELECTIE.
* Niets hier nog
*
*
KLASSE lcl_sum IMPLEMENTATION.
METHODE SOM.
rv_sum = iv_1 * iv_1. "Opzettelijke fout (ik vermenigvuldig in plaats van toe te voegen)
ENDMETHOD. "som
ENDCLASS. “Lcl_sum IMPLEMENTATION.

Testklasse instellen

Maak nu een klasse die fungeert als een testklasse. In SAP moet u het trefwoord VOOR TESTEN toevoegen wanneer u de klasse definieert. Deze toevoeging scheidt deze klasse van de productiecode.

KLASSE lcl_test DEFINITIE VOOR TESTEN
OPENBARE SECTIE.
METHODEN: m_sum VOOR TESTEN.
ENDCLASS. “Lcl_test DEFINITIE
*
KLASSE lcl_test IMPLEMENTATIE.
METHODE m_sum.
ENDMETHOD. “m_sum
ENDCLASS. “Lcl_test IMPLEMENTATION

Implementatie van testmethode

In deze testmethode moet u - De productiecode testen. Dus om de methode SOM van LCL_SUM te kunnen testen, moet u een objectverwijzing naar LCL_SUM instantiëren, de methode SUM aanroepen die de dummy-waarde verzendt.

Gebaseerd op de Dummy-waarde, zou de methode u het resultaat sturen - het werkelijke resultaat van de methode. Op basis van de dummy-waarde weet u wat de verwachte waarde is. Bijv. Als u nummer 3 doorgeeft aan de SOM-methode, geeft dit u het resultaat van 6, aangezien dit optelt bij 3.

Nadat u het werkelijke resultaat van de te testen productiecode of methode hebt ontvangen, moet u de resultaten vergelijken. Als de werkelijke versus verwachte niet overeenkomt, moet u het systeem laten weten dat er iets mis is met de werkelijke versus verwachte en een geschikt bericht weergeven.

KLASSE lcl_test IMPLEMENTATIE.
METHODE m_sum.
DATA: o_cut TYPE REF TO lcl_sum.
DATA: lv_result TYPE i.
*
CREATE OBJECT o_cut.
lv_result = o_cut-> sum (3).
*
cl_aunit_assert => assert_equals (
EXP = 6
act = lv_result
msg = ‘er is iets mis in de uitvoer’
).
ENDMETHOD. “m_sum
ENDCLASS. “Lcl_test IMPLEMENTATION

Resultaten van de eenheidstest

Dit zegt me dat er iets mis is met de implementatie van de productiemethode.

Ja, als u de methode-implementatie van de SOM goed bekijkt, heb ik een typefout in plaats van het gebruik van Summation, ik had Multiplication gebruikt. Dus, ik zou het corrigeren en de test opnieuw uitvoeren om het met succes uit te voeren.

Ik was verslaafd aan TDD. Verbaasd zou het juiste woord zijn.

Wat geweldig was, was de sterk verkorte cyclustijd van ontwikkeling en testen.

Ik was gewend om het grootste deel van een uur code te schrijven voordat ik het probeerde te compileren of uit te voeren. Maar hier werd de code om de 2 minuten uitgevoerd en getest.

Dus, in een notendop, wordt TDD gerealiseerd door middel van korte ontwikkelingscycli die de regel volgen "schrijf eerst eenheidstests, schrijf dan de code, dan refactor, herhaal dan." Eenheidstests zijn geautomatiseerde tests die controleren of functies werken zoals verwacht. Je allereerste unit-test zou moeten mislukken, omdat deze is geschreven voordat je zelfs een codebasis hebt.

Je voegt een beetje toe aan de testcasecode. Je voegt een beetje toe aan de productiecode. De twee codestromen groeien gelijktijdig uit tot complementaire componenten. De tests passen bij de productiecode zoals een antilichaam bij een antigeen past.

Deze maatregel voorkomt dat ontwikkelaars onnodige code schrijven die niet voldoet aan de gegeven test.

En deze hele geïntegreerde aanpak biedt een hele reeks voordelen voor de ontwikkelaar.

U repareert slechte code zonder iets te breken.

Wanneer je slechte code ziet, rol je met je ogen, bid je tot God en spreek je een van de twee uitspraken uit.

· "Dit is een rommel. Ik denk dat ik het op de een of andere manier moet repareren ”.

· "Ik raak het niet aan."

In beide gevallen is er sprake van angst. In feite, onzekerheid.

Wat als mijn code de bestaande functionaliteit breekt?

TDD helpt u precies om die onzekerheid te overwinnen.

Het is belangrijk om erop te wijzen dat ontwikkelaars zich in een TDD-omgeving concentreren op het uitvoeren van tests om bugs te voorkomen in plaats van ze te verwijderen nadat de code is geschreven. Dit is een van de krachtigste voordelen van TDD. Als je een reeks tests hebt die je vertrouwt, verlies je alle angst om wijzigingen aan te brengen. Wanneer u slechte code ziet, maakt u deze gewoon ter plaatse schoon.

En hoe netter uw code, des te minder moeite uw team moet doen om nieuwe functies toe te voegen of de bestaande codebase te wijzigen.

TDD dwingt documentatie af.

Dick Brandon sloeg hem op de spijker toen hij observeerde.

“Documentatie is als seks; als het goed is, is het heel, heel goed, en als het slecht is, is het beter dan niets. "

Documentatie is de wonderolie van programmeren. Managers denken dat het goed is voor programmeurs en programmeurs haten het!

een veel voorkomende reden waarom scoop kruipt is gebrek aan documentatie met duidelijk gedefinieerde vereisten. Dit probleem kan worden beperkt door testgestuurde ontwikkeling.

In een TDD-omgeving schrijven ontwikkelaars eenheidstests om bepaalde codesegmenten te testen. Eenheidstests dienen als specificaties die de precieze functies beschrijven die moeten worden geïmplementeerd. Daarom voorkomen goed gespecificeerde tests dat ontwikkelaars overbodige code schrijven.

En deze eenheidstests zijn documenten. Ze beschrijven het laagste niveau ontwerp van het systeem. Ze zijn ondubbelzinnig, nauwkeurig, geschreven in een taal die het publiek begrijpt en zijn zo formeel dat ze uitvoeren. Ze zijn de beste soort documentatie op laag niveau die kan bestaan.

TDD helpt bij beter ontwerp

De fundamentele vereiste in TDD is dat u uw unit-testgevallen moet schrijven voordat u de code schrijft.

Het probleem met het testen van code is dat je die code moet isoleren. Het is vaak moeilijk om een ​​functie te testen als die functie andere functies aanroept. Om die test te schrijven, moet je een manier bedenken om de functie van alle anderen te ontkoppelen. Met andere woorden, de noodzaak om eerst te testen dwingt je na te denken over goed ontwerp.

Dit zorgt voor een beter, ontkoppeld ontwerp waarin u betere controle hebt over dingen naarmate de code zich ontwikkelt.

Tijdens het vooraf schrijven van testcases kan het in eerste instantie tijd kosten, maar dit biedt veel voordelen. Ontwikkelaars geven toe dat ze voorheen coderegels schreven, zich realiseerden dat hun oplossingen irrelevant waren en vervolgens opnieuw begonnen met coderen.

In tegenstelling tot verouderde coderingspraktijken, stelt TDD ontwikkelaars in staat om terug te gaan naar de tekentafel en zich te concentreren op het vooraf ontwerpen van een lichtgewicht, flexibele architectuur.

En alleen al het vooraf schrijven van testcases voorkomt bugs die later kunnen opduiken, wat tijd, moeite en brandend maagzuur bespaart.

En ten slotte volgt TDD de beste codeermethoden.

TDD promoot goede coderingsprincipes, waaronder DRY, KISS, YAGNI en SOLID.

Het DRY-principe (Don't Repeat Yourself) vertelt ontwikkelaars dat ze moeten voorkomen dat dezelfde code in verschillende delen van hetzelfde systeem wordt herhaald, daarom wordt het ook wel het DIE-principe genoemd (Duplication Is Evil). DRY beveelt ontwikkelaars aan klassen en functies te gebruiken om de systeemfunctionaliteit in te kapselen en een consistente codebasis te behouden.

Het KISS-principe (Keep it Simple, Stupid!) Adviseert ontwikkelaars het wiel niet opnieuw uit te vinden, maar eenvoudige en duidelijke architecturen te bouwen. De essentie van KISS is om over-engineered oplossingen te vermijden.

Het YAGNI-principe (u zult het niet nodig hebben) bestrijdt goudplating. Vergulden lijkt misschien onschadelijk, vooral als een ontwikkelaar graag de bestaande functionaliteit wil verbeteren om een ​​klant te verrassen. Het resulteert echter in extra ontwikkeltijd die een projectvertraging of een ontevreden klant kan veroorzaken. YAGNI maakt het duidelijk: een ontwikkelaar moet alleen toegewezen taken implementeren en vermijd het toevoegen van buitensporige functionaliteit.

SOLID bestaat uit vijf principes in één: enkele verantwoordelijkheid, Open-closed, Liskov-substitutie, interface-segregatie en afhankelijkheidsinversie. Kort gezegd stelt SOLID dat het volgen van deze principes het onderhoud en testen van applicaties vergemakkelijkt.

Kortom, TDD helpt bij het creëren van elegante en eenvoudige code die gemakkelijk te onderhouden is.

Zoals Robert Martin treffend heeft gezegd.

"Schone code ziet er altijd uit alsof het is geschreven door iemand die erom geeft."

Referenties

Extreme programmering: Kent Beck.

Agile Softwareontwikkeling: Robert Martin

Refactoring: Martin Fowler

Over de auteur-:

Ravi Rajan is een wereldwijde IT-programmamanager gevestigd in Mumbai, India. Hij is ook een fervent blogger, Haiku-poëzieschrijver, archeologieliefhebber en geschiedenismaniak. Maak contact met Ravi op LinkedIn, Medium en Twitter.

Dit verhaal is gepubliceerd in The Startup, de grootste publicatie over ondernemerschap van Medium gevolgd door +438.678 mensen.

Abonneer u om onze topverhalen hier te ontvangen.