Hvorfor Test Driven Development (TDD) er den beste måten for robust koding.

Skriv først enhetstester, og skriv deretter koden.

Bildekreditter: Pexels.com

For noen år siden, da jeg først hørte om “Test Driven Development”, var jeg skeptisk.

Selve ideen om å "først skrive enhetstester, deretter skrive koden" var gibberisk for meg.

Hvorfor ville det ikke være det? Vil du skrive enhetstestene dine først? Hvem vil gjøre en klønete ting sånn?

Men jeg hadde vært en profesjonell programmerer i 10 år da, og jeg hadde sett ting komme og gå i bransjen. Jeg visste bedre enn å avfeie noe for hånden, spesielt når utviklere var så tøffe.

Så jeg konsulterte en venn av meg som viste meg et grunnleggende eksempel.

Dette grunnleggende eksemplet har en klasse LCL_SUM med en metode SUM. Denne metodens ansvar er å legge til tallene. Det tar et nummer som en importparameter og legger det til seg selv for å utlede resultatet. La oss kalle denne metoden som en produksjonsmetode.

Koden for klassen var slik:

KLASSE lcl_sum DEFINISJON.
OFFENTLIG seksjon.
METODER: SUM IMPORTERING iv_1 TYPE i
RETURNING VERDI (rv_sum) TYPE i.
ENDCLASS. “Lcl_sum DEFINISJON
*
START-OF-VALG.
* Ingenting her ennå
*
*
KLASSE lcl_sum IMPLEMENTERING.
METODE SUM.
rv_sum = iv_1 * iv_1. “Bevisst feil (jeg multipliserer i stedet for å legge til)
ENDMETHOD. "sum
ENDCLASS. “Lcl_sum IMPLEMENTERING.

Test Class oppsett

Opprett nå en klasse som fungerer som en testklasse. I SAP må du legge til nøkkelordet FOR TESTING når du definerer klassen. Dette tilskuddet skiller denne klassen fra produksjonskoden.

KLASSE lcl_test DEFINISJON FOR TESTING
OFFENTLIG seksjon.
METODER: m_sum FOR TESTING.
ENDCLASS. “Lcl_test DEFINISJON
*
KLASSE lcl_test IMPLEMENTERING.
METODE m_sum.
ENDMETHOD. “m_sum
ENDCLASS. “Lcl_test IMPLEMENTERING

Implementering av testmetode

I denne testmetoden er det du trenger å gjøre - Test produksjonskoden. Så for å kunne teste metoden SUM til LCL_SUM, må du opprette en objektreferanse til LCL_SUM, kalle metoden SUM som sender dummyverdien.

Basert på Dummy-verdien, vil metoden sende deg resultatet - det faktiske resultatet fra metoden. Basert på Dummy-verdi, vet du hva som ville være forventet verdi. F.eks Hvis du passerer nummer 3 til SUM-metoden, vil det gi deg resultatet av 6 som det legger til 3.

Når du har mottatt det faktiske resultatet fra produksjonskoden eller metoden som testes, må du sammenligne resultatene. Hvis den faktiske vs forventet ikke stemmer, må du gi systemet beskjed om at noe er galt med den faktiske vs Forventet og vise en passende melding.

KLASSE lcl_test IMPLEMENTERING.
METODE m_sum.
DATA: o_cut TYPE REF TO lcl_sum.
DATA: lv_result TYPE i.
*
OPPRETT MÅL o_cut.
lv_result = o_cut-> sum (3).
*
cl_aunit_assert => assert_equals (
EXP = 6
handle = lv_result
msg = ‘noe galt i utdata’
).
ENDMETHOD. “m_sum
ENDCLASS. “Lcl_test IMPLEMENTERING

Enhetstest Resultat

Dette forteller meg at det er noe galt i implementeringen av produksjonsmetoden.

Ja, hvis du ser nøye gjennom metoden til implementering av SUM, har jeg en skrivefeil - i stedet for å bruke Summation, hadde jeg brukt Multiplikasjon. Så jeg ville rette det og kjørt testen på nytt for å utføre den.

Jeg ble koblet til TDD. Flabbergasted ville være det rette ordet.

Det som var fantastisk, var den svært reduserte syklustiden for utvikling og testing.

Jeg var vant til å skrive kode i det meste av en time før jeg prøvde å kompilere eller kjøre den. Men her ble koden gjennomført og testet hvert 2. minutt eller så.

Således, i et nøtteskall, realiseres TDD gjennom korte utviklingssykluser som følger regelen "først skriv enhetstester, skriv deretter koden, deretter refaktor, deretter gjenta." Enhetstester er automatiserte tester som sjekker om funksjoner fungerer som forventet. Den aller første enhetstesten din skal mislykkes, siden den er skrevet før du til og med har noen kodebase.

Du legger til litt i test case-koden. Du legger litt til produksjonskoden. De to kodestrømmene vokser samtidig til komplementære komponenter. Testene passer til produksjonskoden som et antistoff passer til et antigen.

Dette tiltaket hindrer utviklere i å skrive unødvendig kode som ikke samsvarer med den gitte testen.

Og hele denne integrerte tilnærmingen gir en liten fordel med fordel for utvikleren.

Du fikser dårlig kode uten å bryte noe.

Hver gang du ser dårlig kode, ruller du øynene, ber til Gud og yter en av de to uttalelsene.

· “Dette er et rot. Jeg antar at jeg på en eller annen måte må fikse det ”.

· “Jeg berører det ikke.”

Uansett er det et element av frykt involvert. Faktisk usikkerhet.

Hva om koden min bryter den eksisterende funksjonaliteten?

TDD hjelper deg nøyaktig å overvinne den usikkerheten.

Det er viktig å påpeke at i et TDD-miljø fokuserer utviklere på å kjøre tester for å forhindre feil i stedet for å fjerne dem etter at koden er skrevet. Dette er en av de kraftigste fordelene med TDD. Når du har en serie tester du stoler på, mister du all frykt for å gjøre endringer. Når du ser dårlig kode, rengjør du ganske enkelt den på stedet.

Og jo ryddigere koden din er, desto mindre krefter må teamet ditt legge til nye funksjoner eller endre den eksisterende kodebasen.

TDD håndhever dokumentasjon.

Dick Brandon slo det smellet på neglen da han observerte.

“Dokumentasjon er som sex; når det er bra, er det veldig, veldig bra, og når det er dårlig, er det bedre enn ingenting. "

Dokumentasjon er ricinusolje for programmering. Ledere synes det er bra for programmerere og programmerere hater det!

en vanlig årsak til at omfangskryp oppstår er mangel på dokumentasjon med klart definerte krav. Dette problemet kan avbøtes gjennom testdrevet utvikling.

I et TDD-miljø skriver utviklere enhetstester for å teste bestemte kodesegmenter. Enhetstester fungerer som spesifikasjoner som beskriver de nøyaktige funksjonene som bør implementeres. Derfor hindrer velspesifiserte tester utviklere i å skrive overflødig kode.

Og disse enhetstestene er dokumenter. De beskriver systemets laveste nivå. De er entydige, nøyaktige, skrevet på et språk som publikum forstår, og er så formelle at de kjører. De er den beste typen dokumentasjon på lavt nivå som kan eksistere.

TDD hjelper med bedre design

Den grunnleggende forutsetningen i TDD er at du må skrive enhetstesttilfellene før du skriver koden.

Problemet med å teste kode er at du må isolere den koden. Det er ofte vanskelig å teste en funksjon hvis den funksjonen kaller andre funksjoner. For å skrive den testen må du finne ut på noen måte å koble fra funksjonen fra alle de andre. Med andre ord, behovet for å teste først tvinger deg til å tenke på god design.

Dette skaper et bedre, frakoblet design der du har bedre kontroll over ting etter hvert som koden utvikles.

Selv om du skriver prøvesaker på forhånd, kan det konsumere tid først, men det gir mange fordeler. Utviklere innrømmer at tidligere brukte de å skrive kodelinjer, skjønte at løsningene deres var irrelevante, og så begynte å kode igjen fra grunnen av.

I motsetning til utdaterte kodingspraksis, lar TDD utviklere gå tilbake til tegnebrettet og konsentrere seg om å utforme en lett, fleksibel arkitektur på forhånd.

Og det faktum å skrive testtilfeller på forhånd forhindrer feil som kan dukke opp senere og sparer tid, krefter og halsbrann.

Og til slutt følger TDD beste kodingspraksis.

TDD fremmer gode kodingsprinsipper inkludert DRY, KISS, YAGNI og SOLID.

DRY (Don’t Repeat Yourself) -prinsippet forteller utviklere å unngå å gjenta den samme koden i forskjellige deler av det samme systemet, og det er derfor det også noen ganger kalles DIE-prinsippet (Duplication Is Evil). DRY anbefaler at utviklere bruker klasser og funksjoner for å innkapsle systemfunksjonalitet og opprettholde en jevn kode.

KISS-prinsippet (Keep it Simple, Stupid!) Råder utviklere til ikke å finne opp hjulet på nytt, men å bygge enkle og tydelige arkitekturer. Essensen i KISS er å unngå overkonstruerte løsninger.

YAGNI-prinsippet (You Ain't Gonna Need It) kjemper mot gullbelegg. Gullbelegg kan virke ufarlig, spesielt hvis en utvikler er ivrig etter å forbedre eksisterende funksjonalitet for å glede en kunde. Det resulterer imidlertid i ekstra utviklingstid som kan føre til prosjektforsinkelse eller en misfornøyd kunde. YAGNI gjør det klart: en utvikler bør bare implementere tildelte oppgaver og unngå å legge til overdreven funksjonalitet.

SOLID består av fem prinsipper i ett: enkelt ansvar, åpen lukket, Liskov substitusjon, grensesnitt segregering og avhengighetsinversjon. For å være kort sier SOLID at det å følge disse prinsippene gjør applikasjoner lettere å vedlikeholde og teste.

I et nøtteskall hjelper TDD med å lage elegant og enkel kode som er lett å vedlikeholde.

Som Robert Martin treffende har sagt.

"Ren kode ser alltid ut som den er skrevet av noen som bryr seg."

referanser

Ekstrem programmering: Kent Beck.

Agile programvareutvikling: Robert Martin

Refactoring: Martin Fowler

Om forfatteren-:

Ravi Rajan er en global IT-programleder basert i Mumbai, India. Han er også en ivrig blogger, Haiku lyrikkforfatter, arkeologientusiast og historie gal. Ta kontakt med Ravi på LinkedIn, Medium og Twitter.

Denne historien er publisert i The Startup, Middels største entreprenørskapspublikasjon fulgt av +438.678 personer.

Abonner for å motta topphistoriene våre her.