Kui olete kunagi pidanud oma koodis olevale veale jälile jõudma, siis teate, kui masendav see võib olla. See pettumus suureneb ainult siis, kui töötate suure koodibaasiga.
Testimine võimaldab teil kontrollida, kas teie koodi tulemused vastavad teie ootustele. Nii saate enne rakenduse juurutamist probleemi hõlpsalt tuvastada ja parandada. Lisaks sellele, et testimine aitab teil koodivigu kiiremini tuvastada, sunnib see teid ka head koodi kirjutama.
1. Staatiline testimine
Staatiline testimine viitab testidele, mis jooksevad ilma koodi käivitamata. See juhtub, kui võrrelda koodi varem seatud kodeerimisreeglitega. Levinud staatilise testimise viisid hõlmavad ebeme ja tüübi kontrollimist.
Linting hõlmab koodi kontrollimist programmeerimis- ja stiilivigade suhtes. Linter analüüsib koodi ja märgib võimalikud vead. Lingimistööriistade näited on EsLint, PyLint ja CSSLint.
Tüübikontroll on trükkimisreeglite ja väärtuste piirangute jõustamise protsess. Mõned programmeerimiskeeled on tugevasti trükitud, mis tähendab, et need tekitavad vigu, kui väärtused pole korralikult trükitud.
Mõnel keelel, nagu JavaScript, on aga nõrk tippimissüsteem ja need on andestavamad. Nendes keeltes on vigu raske tabada ja tüübikontrolli raamatukogu on hädavajalik. JavaScripti puhul saate seda teha kasutage tugeva tippimise jõustamiseks TypeScripti.
Koodi automaatseks analüüsimiseks saate kasutada ka staatilise analüüsi tööriistu. Need tööriistad kontrollivad koodi kvaliteeti ja annavad teada kõigist leitud probleemidest. Staatilise analüüsi tööriistad turul on näiteks SonarQube, DeepSource ja SpotBugs. Staatilise analüsaatori valimisel veenduge, et see toetaks teie programmeerimiskeelt.
2. Ühikutestid
Ühiktestid kontrollivad rakenduse väikseimaid testitavaid osi, et teha kindlaks, kas need toimivad ootuspäraselt. Saate kirjutada funktsioonide, moodulite, objektide jms ühikteste.
Kuigi ühikutestid võivad olla aeganõudvad, peaksid need säästma rohkem aega, kui kulutate rakenduse silumine kui olete kogu koodi kirjutanud.
Üldiselt koosneb ühikutestimine neljast etapist:
- Testide koostamine
- Testi läbivaatamine
- Baselimine
- Testi täitmine.
Saate ühikuteste kirjutada käsitsi või automatiseerida, kasutades ühikutestimise raamistikku. Käsitsi testimisel kirjutaksite vajaliku funktsiooni või üksuse testimiseks koodi, seejärel kustutage hiljem testimiskood.
Kui kasutate raamistikku, määrake testitav üksus ja oodatavad tulemused ning seejärel käivitage test. Testimisraamistik logib seejärel ebaõnnestunud ja läbinud testid. Üldiselt on parem kasutada raamistikku, kuna see on kiirem.
Ühikutesti kirjutamisel veenduge, et testitav üksus oleks sõltumatu. Kui see tugineb välistele andmetele, näiteks muutujatele, võite kasutada pilke. Funktsioonid asendavad seadmes kasutatud puuduvad andmed.
Näiteks kui testite funktsiooni, mis tugineb API-st hangitud andmed, saate testimise eesmärgil luua võltsandmeobjekti.
3. Integratsioonitestid
Integratsioonitestid kontrollivad, kuidas erinevad komponendid koos toimivad. See on erinevalt ühikutestidest, mis testivad sõltumatuid komponente. Kirjutate integratsiooniteste pärast ühikteste.
Integratsioonitestid on olulised, kuna need tagavad teie rakenduse loogika kehtivuse.
Näiteks kaaluge kahte moodulit: üks, mis toob andmeid API-st ja teine, mis neid analüüsib. Sooviksite tagada, et teie kood tõmbaks õiged andmed ja analüüsiks neid õigesti.
Siin tulebki sisse integratsioonitestimine. See tagab, et loogikavoolus ühest moodulist teise ei esine vigu.
4. End-to-End testid
Täielik testimine kontrollib rakenduste voogu lõppkasutaja vaatenurgast. Protsess testib rakendust algusest lõpuni, kuna kasutaja kasutab rakendust. Need testid pakuvad rohkem katvust kui ühikutestid või integratsioonitestid.
Täielikud testid määravad rakenduse sõltuvused, andmebaasid ja välised suhtlused. Nad kordavad reaalse maailma stsenaariumi nii täpselt kui võimalik.
Näiteks registreerumisvormi testimisel testib täielik test erinevaid stsenaariume, näiteks:
- Kasutaja, kes esitab nii e-posti aadressi kui ka parooli
- Kasutaja, kes kasutab nõrka parooli
- Kasutaja, kes kasutab kehtetut e-posti aadressi
- Kasutaja, kes saadab ainult meili
- Ainult parooli esitav kasutaja
Lõpptestid tagavad, et rakendus käitub nendes stsenaariumides ootuspäraselt.
Testide kirjutamine vs. Koodi kirjutamine
Rakenduse testimine arendusprotsessi varajases staadiumis on ülioluline. Kuigi kõik need testid on hädavajalikud, on oluline leida teie jaoks sobiv tasakaal. Vastasel juhul kulutate liiga palju aega koodi asemel testide kirjutamisele.
Ühiku testimine on enamiku rakenduste jaoks ülioluline ja võiksite pühendada sellele piisavalt aega. Kui olete ühikutestid läbi viinud, võite olla kindel, et teie rakenduse ehitusplokid töötavad õigesti.
