Kio estas Test Driven Development, aliroj kaj avantaĝoj

Test Driven Development (TDD) estas programaro-disvolva aliro kie testkazoj estas evoluigitaj por specifi kaj validigi kion la kodo faros.

Praktike testkazoj por ĉiu funkcio estas kreitaj kaj testitaj antaŭ ol la programaro estas liberigita, kaj se la testo malsukcesas, nova kodo estas skribita (aŭ reverkita aŭ flikita) por pasigi la teston kaj fari la kodon simpla kaj senerara.

Test Driven Development (TDD) komenciĝas per desegnado kaj evoluigado de testoj por ĉiu eta funkcio en aplikaĵo. La TDD-kadro instrukcias programistojn skribi novan kodon nur se aŭtomatigita testo malsukcesis. Ĉi tiu aliro evitas kodduobligon. La kompleta TDD-modulo estas test-movita evoluo.

Test Driven Development (TDD) originis kiel parto de pli granda softvardezajnparadigmo konata kiel Extreme Programming (XP), kiu estas parto de la Agile softvarmetodaro.

La simpla koncepto de TDD estas skribi kaj ripari malsukcesajn testojn antaŭ skribi novan kodon (antaŭ evoluo). Ĉi tio helpas eviti kodon duobligon dum ni skribas malgrandan kvanton da kodo samtempe por pasigi testojn. (Testoj estas nenio pli ol postulkondiĉoj, kiujn ni devas testi por kontentigi ilin).

Test-movita evoluo estas procezo de evoluigado kaj funkciado de aŭtomatigitaj testoj antaŭ la fakta evoluo de la aplikaĵo. Tial, TDD ankaŭ estas foje nomita Test First Development.

Fazoj de la TDD-aliro

Antaŭ ol iu nova kodo estas skribita, la programisto unue devas krei malsukcesan unuteston. Tiam, la programisto - aŭ paro, aŭ mafio - kreas ĝuste sufiĉe da kodo por kontentigi tiun postulon. Post kiam la testo pasas, la programisto povas refaktori la projekton, farante plibonigojn sen ŝanĝi la konduton.

Dum TDD temigas ununivelajn programinteragojn, ekzistas aliaj popularaj metodoj, kiel ekzemple akcepto-test-movita evoluo (ATDD) aŭ kondut-movita evoluo (BDD), kiuj temigas testojn kiuj povas esti komprenitaj fare de klientoj.

Tiuj metodoj implikas konstrui realmondajn ekzemplojn kiel kunlaboraj testoj inter la inĝenieristiko kaj la kliento antaŭ kodigo, kaj tiam ruli la testojn post kodigo por montri ke la kodo estas efektivigita. Havi la provojn konatajn anticipe plibonigas la kvaliton de la unua fojo. ATDD kaj BDD postulas programistojn, testistojn kaj la komercan flankon labori kune por imagi kaj diskuti la programaron kaj ĝiajn implicojn antaŭ ol la kodo estas kreita.

Avantaĝoj de TDD

Test-movita evoluo povas produkti altkvalitajn aplikojn en malpli da tempo ol estas ebla kun pli malnovaj metodoj. Sukcesa efektivigo de TDD postulas programistojn kaj testistojn precize antaŭvidi kiel la aplikaĵo kaj ĝia funkcieco estos uzataj en la reala mondo.

TDD konstruas regresan teston kiel kromefikon, kiu povas minimumigi homan manan testadon, trovante problemojn pli frue, kondukante al pli rapidaj solvoj. La metoda naturo de TDD certigas multe pli altan unuafojan priraportadon kaj kvaliton ol la klasikaj fazaj kodaj cikloj > testi > ripari > retesti. Ĉar testado estas farita frue en la dezajnociklo, la tempo kaj mono elspezitaj por senararigado poste estas minimumigitaj.

Atenditaj avantaĝoj:

• signifaj reduktoj en difektoprocentoj, je la kosto de modera pliiĝo en komenca evoluiniciato
• superkostoj estas pli ol kompensitaj per redukto de fortostreĉo en la finaj stadioj de projektoj
• TDD kondukas al pli bonaj dezajnokvalitoj en la kodo kaj, pli ĝenerale, pli alta grado da "interna" aŭ teknika kvalito, ekzemple plibonigante la kohezion kaj kunligajn metrikojn.

Malavantaĝoj de TDD

TDD postulas konsiderindan kapablon esti sukcesa, precipe sur la unuonivelo. Multaj heredaĵsistemoj simple ne estas konstruitaj kun unutestado en menso, farante malebla izoli komponentojn por testado.

Ankaŭ al multaj programistoj mankas la kapabloj por izoli kaj krei puran kodon. Ĉiuj grupanoj devas krei kaj konservi unutestojn aŭ ili rapide malnoviĝos. Kaj organizo rigardanta TDD devos investi tempon, malrapidigi iom nun por iri pli rapide poste.

Fine, kiel kun iu ajn metodo, la finrezultoj de TDD estas nur same bonaj kiel la testoj kiuj estis uzataj, kiom precize ili estis faritaj, kaj kiom ili imitas la kondiĉojn renkontitajn de uzantoj de la fina produkto.

Oftaj eraroj:

• forgesante fari testojn ofte
• skribi tro da testoj samtempe
• skribi testojn kiuj estas tro grandaj aŭ malpuraj
• skribi tro bagatajn provojn, kiel preterlasi asertojn
• skribi testojn por bagatela kodo
• parta adopto: nur kelkaj programistoj en laborgrupo uzas TDD
• malbona prizorgado de testserio, plej ofte kondukante al testserio kun malpermese longa rultempo
• testserio forlasita (t.e. malofte aŭ neniam funkciigas) - foje pro malbona prizorgado, foje pro teamspezo

TDD-filozofio

TDD permesas al la programisto fari bebpaŝojn dum verkado de programaro. La testo estas skribita antaŭ testado de la funkcieco kaj certigas, ke la aplikaĵo taŭgas por testebleco. Testado sur malgranda kvanto de kodo estas farita por kapti erarojn kiuj okazas en la testita kodo. Tiam la funkcieco estas efektivigita. Tio estas referita kiel "ruĝa verda refaktoro" kie ruĝa signifas fiaskon kaj verda montras enirpermesilon. Ĉi tiuj paŝoj tiam estas ripetitaj. La unua celo de programisto estas koncentriĝi pri la ĉeesta tasko kaj venki ĝin.

La malsamaj stadioj implikitaj en testmovita evoluciklo estas:

• Aldonu Teston: Ĉiu nova funkcio en TDD komenciĝas per testo, kiu devas malsukcesi kiam ĝi estas metita antaŭ ol iu ajn funkcio estas efektivigita. La antaŭkondiĉo por verki teston antaŭ efektivigi la funkcion estas klara kompreno de la postulo de la programisto. Ĉi tio estas atingita per uzantrakontoj kaj uzkazoj. Do programisto komprenas la postulon antaŭ skribi la programkodon.
• Rulu ĉiujn provojn kaj kontrolu ĉu la nova kodo malsukcesas: ĉi tio certigas, ke la testa jungilaro funkcias ĝuste kaj ke la nova testo ne malsukcesas sen nova kodo. Ĉi tiu paŝo ankaŭ kontrolas la teston kaj forigas la eblecon, ke la nova testo ĉiam trapasos.
• Skribu Kodon: La sekva paŝo estas skribi la kodon, kiu purigas la teston. La nova kodo ne estas perfekta sed poste estas modifita laŭ la postuloj. Ĝi estas desegnita simple por testado kaj ne enhavas aliajn funkciojn.
• Kuru Aŭtomatigitajn Testojn: Se ĉiu testkazo produktita facile sukcesas la teston, tio signifas, ke la kodo plenumas ĉiujn postulatajn specifojn. Tiam la fina fazo de la ciklo povas esti komencita.
• Refaktoriga kodo: Ĉi tio similas al forigo de duobligo. Refactoring ne rompas ajnan ekzistantan funkciecon kaj helpas forigi duobligon inter produktado kaj testa kodo. La kodo nun estas purigita laŭbezone.
• Ripeto: La ciklo ripetas kiel en la antaŭaj kazoj kun nova testo. La esenca postulo estas, ke la paŝa grandeco estas malgranda, kun ĉirkaŭ 1-10 ŝanĝoj inter ĉiu provo. Se la nova kodo malsukcesas novan teston, la programisto devus fari pli da sencimigado. Kontinua integriĝo disponigas reigeblajn transirejojn.

Ercole Palmeri