Mine sisu juurde

Testimisel põhinev arendus

Allikas: Vikipeedia

Testimisel põhinev arendus [1](inglise keeles test-driven development, lühend TDD) on tarkvaraarenduse meetod, kus testid kirjutatakse enne tarkvara ennast. Arendusprotsess koosneb lühikestest iteratsioonidest, kus esmalt kirjutatakse ebaõnnestuv test ning seejärel minimaalne kood, et see test läbi läheks. Selline arendus tagab olukorra, kus kogu kood on alati testitud. Sellisel viisil kirjutatud koodi on kergem refaktoreerida ning testid aitavad ka programmi eeldatavat käitumist dokumenteerida. Testimisel põhinevat arendust rakendatakse ka olemasoleva koodi täiustamisel ja silumisel.[2]

Testimisel põhineva arenduse loojaks või taasavastajaks[3] peetakse USA tarkvaraarendajat Kent Becki. Ta väidab, et testimisel põhinev arendus aitab luua lihtsa disainiga tarkvara ja tõstab selle usaldusväärsust.[4] Testimisel põhinev arendus on muutunud populaarsemaks ning selle vastu tuntakse üha enam huvi ka suurtes ettevõtetes.[5]

Testimisel põhineva arenduse tsükkel

[muuda | muuda lähteteksti]
Testimisel põhineva arenduse tsükkel

Järgnev tsükkel põhineb raamatul "Test-Driven Development by Example".[4]

1. Testi kirjutamine
Testimisel põhinev arendus algab uue testi kirjutamisega. Test peab defineerima ühe funktsiooni või mõnda funktsiooni täiustama. Testi kirjutajal peab olema selge arusaam nõuetest testitavale funktsionaalsusele. Testimisel põhinev arendus sunnib seega arendajat tutvuma rakenduse nõudmistega enne koodi kirjutamist.
2. Kõikide testide käitamine
Selle sammu eesmärk on veenduda, et testid töötavad nii, nagu ette nähtud. Oluline on, et lisatud uus test ei lähe läbi. See näitab, et testitavat funktsiooni veel ei eksisteeri ning seega on vaja koodi kirjutades see implementeerida. Arendaja saab olla kindel, et test ebaõnnestus eeldataval põhjusel. Lisaks välistab see samm võimaluse, et uus test läheb alati läbi.
3. Koodi kirjutamine
Eesmärk on kirjutada kood nii, et test läbi läheks. Kirjutatav kood ei pea olema veel lõplik ja rahuldav. Seda koodi täiustatakse viienda sammu juures. Testi õnnestumine on selles sammus kirjutatava koodi ainuke eesmärk. See kood ei tohi teha midagi muud.
4. Kõikide testide käitamine
Kui kõik testid koos uue testiga läbi lähevad, võib arendaja kindel olla, et kirjutatud kood vastab testitavatele nõuetele ega muuda olemasolevat koodi. Kui kõik testid läbi ei lähe, peab muutma lisatud koodi seni, kuni testid jälle läbi lähevad.
5. Refaktoreerimine
Kuna nüüd on olemas test, mis kontrollib õiget käitumist, saab pärast koodi muutmist veenduda, et kogu kood endiselt töötab. Uus kood tuleb nüüd korrastada, et parandada koodi loetavust ja hallatavust.

Testimisel põhinev arendus koosneb selliste tsüklite kordamisest. Igas sammus tehtud muudatuste hulk peaks olema väike, koosnedes 1–10 muudatusest. Sellisel juhul on testide läbikukkumise korral arendajal kerge vigu leida ja parandada. Väliseid teeke kasutades peab veenduma, et testi ei testiks teegi funktsionaalsust, välja arvatud juhul, kui teegi usaldusväärsus on kaheldav.[5]

Eelised

[muuda | muuda lähteteksti]

2005. aastal tehtud uuringu käigus leiti, et testimisel põhinev arendus suurendas programmeerijate produktiivsust, kuna nad kirjutasid rohkem teste.[6] Testimisel põhinev arendus aitab lisaks valideerimisele ka tarkvara disainida.[7] Kuna arendajad kirjutavad teste enne koodi, siis peavad nad enne läbi mõtlema, kuidas arendatavat funktsionaalsust kasutatakse. Seega keskendutakse enne liidesele ja alles siis implementatsioonile.

Testimisel põhineva arenduse käigus kirjutatakse kood väikeste osade kaupa. See aitab arendajal keskenduda ühele eesmärgile, erindid ja vigadega tegelemine tuleb implementatsioonile juurde alles siis, kui mõni test neid nõuab. Sellisel viisil kirjutatud kood on alati kaetud vähemalt ühe testiga, mis tõstab koodi usaldusväärsust.[8]

Testimisel põhinev arendus nõuab suurema hulga koodi kirjutamist, kuna testide arv on kõrge. Müller ja Padberg väidavad, et sellest hoolimata võib kogu koodi kirjutamiseks kuluv aeg olla lühem.[9] Suur kogus teste aitab piirata vigade arvu koodis. Varases staadiumis leitud vigu on kergem ja odavam parandada ning see võimaldab vältida keerulisi silumisprotsesse.[10]

Kuna testimisel põhinev arendus nõuab, et arendajad teeksid korraga väikseid muudatusi, tagab see modulaarsema ja paindlikuma koodi, mida on kerge edasi arendada. Tekkivad klassid, funktsioonid ja liidesed on väiksemad, loetavamad ja konkreetsemad.[8]

Puudused

[muuda | muuda lähteteksti]

Testimisel põhinev arendus ei pruugi alati piisavalt funktsionaalsust testida, kuna kasutatakse ainult ühikteste.[11] Selline olukord tekib, kui on vaja testida kasutajaliideseid, tööd andmebaasidega või kindlaid võrgukonfiguratsioone. Kuna testid ja kood on enamasti sama arendaja kirjutatud, võivad ühe arendaja vead koodi sisse jääda. Üks arendaja võib unustada mõne olukorra testimise. Samuti võib olla arusaamatusi nõudmiste osas, mis võib viia testideni, mis lähevad läbi, aga ei testi eeldatavat käitumist.[12]

Testide haldamine võib muutuda kulukaks ja aeganõudvaks, kui need on halvasti implementeeritud või vigased.[13]

Vaata ka

[muuda | muuda lähteteksti]

Viited

[muuda | muuda lähteteksti]
  1. ↑ Hardik Shah (15. aprill 2019). "What is TDD? [Roadmap to Implement TDD in Your Organization]".
  2. ↑ Feathers, M. Working Effectively with Legacy Code, Prentice Hall, 2004
  3. ↑ Beck, Kent (11.05.2012). "Why does Kent Beck refer to the "rediscovery" of test-driven development?". Vaadatud 28.12.2018.
  4. ↑ 4,0 4,1 Beck, K. Test-Driven Development by Example, Addison Wesley - Vaseem, 2003
  5. ↑ 5,0 5,1 Newkirk, JW and Vorontsov, AA. Test-Driven Development in Microsoft .NET, Microsoft Press, 2004.
  6. ↑ Erdogmus, Hakan; Morisio, Torchiano. "On the Effectiveness of Test-first Approach to Programming". Proceedings of the IEEE Transactions on Software Engineering, 31(1). January 2005. (NRC 47445). Originaali arhiivikoopia seisuga 22.12.2014. Vaadatud 03.12.2018. We found that test-first students on average wrote more tests and, in turn, students who wrote more tests tended to be more productive.
  7. ↑ Mayr, Herwig (2005). Projekt Engineering Ingenieurmässige Softwareentwicklung in Projektgruppen (2., neu bearb. Aufl. ed.). München: Fachbuchverl. Leipzig im Carl-Hanser-Verl. Lk 239. ISBN 978-3446400702.
  8. ↑ 8,0 8,1 Kumar, Shaweta; Bansal, Sanjeev. "Comparative Study of Test Driven Development with Traditional Techniques" (PDF). Vaadatud 03.12.2018.
  9. ↑ Müller, Matthias M.; Padberg, Frank. "About the Return on Investment of Test-Driven Development" (PDF). Universität Karlsruhe, Germany. Lk 6. Originaali (PDF) arhiivikoopia seisuga 8.11.2017. Vaadatud 03.12.2018.
  10. ↑ Leon, Janet (28.02.2015). "Arhiivikoopia". Originaali arhiivikoopia seisuga 7.12.2018. Vaadatud 12.12.2018.{{cite web}}: CS1 hooldus: arhiivikoopia kasutusel pealkirjana (link)
  11. ↑ "Problems with TDD". Dalkescientific.com. 29.12.2009. Vaadatud 03.12.2018.
  12. ↑ Hunter, Andrew (19.10.2012). "Are Unit Tests Overused?". Simple-talk.com. Vaadatud 12.06.2018.
  13. ↑ "Fragile Tests". xunitpatterns.com. Vaadatud 03.12.2018.
Pärit leheküljelt "https://et.wikipedia.org/w/index.php?title=Testimisel_põhinev_arendus&oldid=6640757"