Pirmais testa izstrāde ar FitNesse

Dažu pēdējo gadu laikā esmu strādājis visās testēšanas procesa lomās, izmantojot servera puses JavaScript, Perl, PHP, Struts, Swing un uz modeļiem balstītas arhitektūras. Visi projekti atšķīrās, taču tiem visiem bija dažas kopīgas iezīmes: termiņi kavējās, un projektiem bija grūtības izpildīt to, ko pasūtītājs tiešām nepieciešams.

Katram projektam bija kaut kādas prasības, daži bija ļoti detalizēti, citi - tikai dažas lappuses. Šīs prasības parasti piedzīvoja trīs fāzes:

• Tos uzrakstīja (vai nu pasūtītājs, vai darbuzņēmējs), un viņi saņēma kaut kādu oficiālu akceptu
• Testētāji centās strādāt ar prasībām un uzskatīja, ka tās ir vairāk vai mazāk nepietiekamas
• Projekts iegāja pieņemšanas testēšanas fāzē, un klients pēkšņi atcerējās visādas lietas, kas programmatūrai vajadzīgas papildus / savādāk

Pēdējais posms noveda pie izmaiņām, kā rezultātā tika nokavēti termiņi, kas radīja stresu izstrādātājiem, kas savukārt izraisīja vairāk kļūdu. Kļūdu skaits sāka strauji pieaugt, un kopējā sistēmas kvalitāte pasliktinājās. Izklausās pazīstami?

Apsvērsim, kas notika nepareizi iepriekš aprakstītajos projektos: klients, izstrādātājs un testētājs nestrādāja kopā; viņi nodeva prasības tālāk, bet katrai lomai bija atšķirīgas vajadzības. Turklāt izstrādātāji parasti izstrādāja sava veida automatizētus testus, un testētāji mēģināja automatizēt arī dažus testus. Parasti viņi nevarēja pietiekami koordinēt testēšanu, un daudzi priekšmeti tika pārbaudīti divas reizes, bet citi (parasti cietās daļas) vispār. Un klients neredzēja testus. Šajā rakstā ir aprakstīts veids, kā atrisināt šīs problēmas, apvienojot prasības ar automatizētiem testiem.

Ievadiet FitNesse

FitNesse ir wiki ar dažām papildu funkcijām, lai aktivizētu JUnit testus. Ja šie testi tiek apvienoti ar prasībām, tie kalpo kā konkrēti piemēri, tādējādi padarot prasības vēl skaidrākas. Turklāt testa dati ir loģiski sakārtoti. Tomēr vissvarīgākais par FitNesse lietošanu ir ideja aiz tā, kas nozīmē, ka prasības izrādās (daļēji) rakstītas kā testi, padarot tos pārbaudāmus un līdz ar to arī pārbaudāmus.

Izmantojot FitNesse, izstrādes process varētu izskatīties šādi: Prasību inženieris prasības raksta FitNesse (nevis Word). Viņš cenšas pēc iespējas vairāk piesaistīt klientu, taču to parasti ikdienā nevar sasniegt. Testētājs atkārtoti palūrē dokumentu un jau no pirmās dienas uzdod sarežģītus jautājumus. Tā kā testētājs domā citādi, viņš nedomā: "Ko programmatūra darīs?" bet "Kas var noiet greizi? Kā es varu to salauzt?" Izstrādātājs domā vairāk kā prasību inženieris; viņš vēlas uzzināt: "Kas jādara programmatūrai?"

Testētājs testus sāk rakstīt agri, kad prasības vēl nav pat izpildītas. Un viņš tos ieraksta prasībās. Testi kļūst par daļu no ne tikai prasībām, bet arī ar prasību pārskatīšanas / pieņemšanas procesu, kam ir dažas svarīgas priekšrocības:

• Arī klients sāk domāt par testiem. Parasti viņa pat iesaistās to veidošanā (jūs varētu būt pārsteigts, cik jautri viņa ar to var izklaidēties).
• Specifikācija kļūst daudz detalizētāka un precīzāka, jo testi parasti ir precīzāki nekā tikai teksts.
• Jau laikus domājot par reāliem scenārijiem, nodrošinot testa datus un aprēķinot piemērus, programmatūras skatījums kļūst daudz skaidrāks - piemēram, prototips, tikai ar vairāk funkcijām.

Visbeidzot, prasības tiek nodotas izstrādātājam. Viņam tagad ir vieglāk strādāt, jo specifikācija, visticamāk, nemainīsies un visu iekļauto piemēru dēļ. Apskatīsim, kā šis process atvieglo izstrādātāja darbu.

Vispirms tiek ieviests tests

Parasti visgrūtāk testa sākumā ir tas, ka neviens nevēlas tērēt tik daudz laika, lai rakstītu testus, tikai tad, lai atrastu veidu, kā likt tiem darboties. Izmantojot iepriekš aprakstīto procesu, izstrādātājs saņem funkcionālos testus kā daļu no sava līguma. Viņa uzdevumi mainās no “Izveido lietu, ko es vēlos, un tu esi paveikts, līdz es pārbaudīšu tavu darbu un veicu izmaiņas” uz “Liec šiem testiem darboties un viss ir paveikts”. Tagad visiem ir labāka ideja par to, ko darīt, kad darbs jāpabeidz un kur atrodas projekts.

Ne visi šie testi būs automatizēti un ne visi būs vienības testi. Testus mēs parasti iedala šādās kategorijās (sīkāka informācija sekos):

• Uz datiem balstīti testi, kas jāievieš kā vienības testi. Aprēķini ir tipisks piemērs.
• Atslēgvārdu vadīti testi, kas automatizē lietojumu lietošanu. Tie ir sistēmas testi, un tiem nepieciešama lietojumprogrammas darbība. Noklikšķina uz pogām, tiek ievadīti dati un tiek pārbaudītas iegūtās lapas / ekrāni, lai saturētu noteiktas vērtības. Pārbaudes komanda parasti īsteno šos testus, taču daži izstrādātāji arī no tiem gūst labumu.
• Manuāli testi. Šie testi ir vai nu pārāk dārgi, lai tos automatizētu, un iespējamās kļūdas nav pietiekami smagas, vai arī tās ir tik būtiskas (sākuma lapa netiek parādīta), ka to bojājumi tiktu atklāti uzreiz.

Kad es pirmo reizi izlasīju par FitNesse 2004. gadā, es smējos un teicu, ka tas nekad nedarbosies. Ideja ierakstīt manus testus wiki, kas tos automātiski pārveidoja par testiem, šķita pārāk absurda. Izrādījās, es kļūdījos. FitNesse patiešām ir tikpat vienkārša, kā šķiet.

Šī vienkāršība sākas ar instalēšanu. Vienkārši lejupielādējiet visu FitNesse izplatīšanu un izpakojiet to. Šajā diskusijā es pieņemu, ka esat nojaucis izplatīšanu C: \ fitnesse.

Sāciet FitNesse, palaižot run.bat (palaist.sh Linux) skripts C: \ fitnesse. Pēc noklusējuma FitNesse 80. portā vada tīmekļa serveri, taču, pievienojot, varat norādīt citu portu, teiksim, 81 -p 81. uz pakešfaila pirmo rindiņu. Tas ir viss, kas tam ir; tagad varat piekļūt FitNesse vietnē // localhost: 81.

Šajā rakstā es izmantoju FitNesse Java versiju operētājsistēmā Windows. Tomēr piemērus var izmantot arī citām versijām (Python, .Net) un platformām.

Daži testi

FitNesse tiešsaistes dokumentācijā ir sniegti daži vienkārši piemēri (salīdzināmi ar bēdīgi slaveno JUnit naudas piemēru), lai sāktu darbu. Viņiem ir lieliski mācīties lietot FitNesse, taču tie nav pietiekami sarežģīti, lai pārliecinātu dažus skeptiķus. Tāpēc es izmantošu reālā pasaules piemēru no viena no saviem nesenajiem projektiem. Esmu ievērojami vienkāršojis problēmu, un kods, kas nav ņemts tieši no projekta, tika uzrakstīts ilustratīviem nolūkiem. Tomēr šim piemēram jābūt pietiekami sarežģītam, lai parādītu FitNesse vienkāršības spēku.

Pieņemsim, ka mēs strādājam pie projekta, kurā tiek ieviesta sarežģīta uzņēmuma Java balstīta programmatūra lielai apdrošināšanas sabiedrībai. Produkts darbosies ar visu uzņēmuma darbību, ieskaitot klientu un līgumu pārvaldību un maksājumus. Piemēram, mēs aplūkosim nelielu šīs lietojumprogrammas daļu.

Šveicē vecākiem ir tiesības uz vienu bērna pabalstu katram bērnam. Viņi saņem šo pabalstu tikai tad, ja ir zināmi apstākļi, un to summa mainās. Šī ir šīs prasības vienkāršota versija. Mēs sāksim ar "tradicionālajām" prasībām un pēc tam pārvietosim tās uz FitNesse.

Pastāv vairākas bērna pabalsta fāzes. Prasība sākas ar bērna piedzimšanas mēneša pirmo dienu un beidzas tā mēneša pēdējā dienā, kad bērns sasniedz vecuma robežu, pabeidz mācekli vai nomirst.

Sasniedzot 12 gadu vecumu, prasība tiek paaugstināta līdz 190 CHF (Šveices oficiālais valūtas simbols), sākot ar dzimšanas mēneša pirmo dienu.

Vecāku pilna un nepilna laika nodarbināšana rada dažādas prasības, kā sīki aprakstīts 1. attēlā.

Pašreizējo nodarbinātības līmeni aprēķina pēc aktīvajiem darba līgumiem. Līgumam jābūt derīgam, un, ja ir noteikts beigu datums, tam jāatrodas "aktivizācijas periodā". 2. attēlā parādīts, cik daudz naudas ir tiesīgs saņemt vecākiem, atkarībā no bērna vecuma.

Noteikumi, kas regulē šos maksājumus, tiek pielāgoti reizi divos gados.

Pirmajā lasījumā specifikācija varētu izklausīties precīzi, un izstrādātājam jāspēj to viegli ieviest. Bet vai mēs tiešām esam pārliecināti par robežnosacījumiem? Kā mēs pārbaudītu šīs prasības?

Scenāriji var būt ļoti noderīgi, lai atrastu izņēmumus un robežnosacījumus, jo tie ir labs veids, kā panākt, lai domēnu eksperti runātu par biznesu.

Scenāriji

Lielākajai daļai projektu prasību inženieris nodod specifikāciju izstrādātājam, kurš pēta prasības, uzdod dažus jautājumus un sāk izstrādāt / kodēt / testēt. Pēc tam izstrādātājs programmatūru nodod testa komandai un pēc nelielas pārstrādes un labošanas nodod to klientam (kurš, iespējams, izdomās dažus izņēmumus, kas prasa izmaiņas). Teksta pārvietošana uz FitNesse šo procesu nemainīs; tomēr pievienojot piemērus, scenārijus un testus.

Scenāriji ir īpaši noderīgi, lai iegūtu bumbu ripināšanas laikā. Daži piemēri seko. Atbildot uz jautājumu par to, cik liels ir bērna pabalsts katram, būs daudz skaidrs:

• Marija ir viena no vecākiem. Viņai ir divi dēli (Bobs, 2 un Pēteris, 15), un viņa strādā sekretāri, nepilnu slodzi (20 stundas nedēļā).
• Marija zaudē darbu. Vēlāk viņa strādā 10 stundas nedēļā par veikala pārdevēju un vēl 5 stundas par auklīti.
• Pāvilam un Larai ir meita (Liza, 17), kurai ir fiziskas grūtības, un dēls (Frenks, 18), kurš joprojām mācās universitātē.

Vienīgi runāšana ar šiem scenārijiem palīdzēs testēšanas procesam. Izpildot tos manuāli programmatūrā, gandrīz noteikti atradīsit dažus vaļīgus galus. Domājat, ka mēs to nevaram izdarīt, jo mums vēl nav prototipa? Kāpēc ne?

Atslēgvārdu vadīta testēšana

Prototipa modelēšanai var izmantot testēšanu ar atslēgvārdiem. FitNesse ļauj mums definēt uz atslēgvārdiem balstītus testus (sīkāku informāciju skatiet sadaļā “Pilnīgi ar datiem pamatota automatizēta testēšana”). Pat tad, ja nav programmatūras, lai (automātiski) veiktu testus, atslēgvārdu vadīti testi palīdzēs daudz.

3. attēlā parādīts, kā varētu izskatīties uz atslēgvārdiem balstīts tests. Pirmajā slejā tiek parādīti FitNesse atslēgvārdi. Otrajā kolonnā ir norādītas metodes Java klasē (mēs tās rakstām, un tām jāievēro ierobežojumi, kas Java nosaukumos noteikti metožu nosaukumiem). Trešā kolonna attēlo datus, kas metodē ievadīti no otrās kolonnas. Pēdējā rinda parāda, kā varētu izskatīties neizdevies tests (nokārtotie testi ir zaļi). Kā redzat, ir diezgan viegli uzzināt, kas notika nepareizi.

Šādus testus ir viegli un pat jautri izveidot. Testētāji bez programmēšanas iemaņām var tos izveidot, un klients tos var izlasīt (pēc īsa ievada).

Šādi definējot testus, tieši blakus prasībai, ir dažas svarīgas priekšrocības salīdzinājumā ar tradicionālo testa gadījumu definīciju, pat bez automatizācijas:

• Konteksts ir pie rokas. Pārbaudes gadījumu var uzrakstīt ar pēc iespējas mazāk darba, un tas joprojām ir precīzs.
• Ja prasība mainās, pastāv lielas izredzes, ka arī tests mainīsies (nav ļoti iespējams, ja tiek izmantoti vairāki rīki).
• Pārbaudi var izpildīt uzreiz, lai parādītu, kas jālabo, lai šī jaunā / mainītā prasība darbotos.

Testa automatizēšanai tiek izveidots plāns programmatūras slānis, kas tiek deleģēts reālajam testa kodam. Šie testi ir īpaši noderīgi manuālo GUI testu automatizēšanai. Es izstrādāju testēšanas sistēmu, kas balstīta uz HTTPUnit, lai automatizētu vietņu testēšanu.

FitNesse automātiski izpilda kodu:

pakete stephanwiesner.javaworld;
importa fit.ColumnFixture;
publiskā klase ChildAllowanceFixture paplašina ColumnFixture {public void personButton () {System.out.println ("nospiežot personas pogu"); } public void securityNumber (int numurs) {System.out.println ("ievadot drošības numuru" + numurs); } public int childAllowance () {System.out.println ("bērna pabalsta aprēķināšana"); atgriešanās 190; } [...]} 

Testu rezultātus var pārbaudīt arī FitNesse (skat. 4. attēlu), kas ļoti palīdz atkļūdot. Atšķirībā no JUnit, kur tiek atturēts rakstīt atkļūdošanas ziņojumus, es uzskatu, ka tie ir absolūti nepieciešami, strādājot ar automatizētiem tīmekļa testiem.

Pārbaudot tīmekļa lietojumprogrammu, kļūdas lapas tiek iekļautas FitNesse lapā un tiek parādītas, padarot atkļūdošanu daudz vieglāku nekā darbu ar žurnāla failiem.

Uz datiem balstīta testēšana

Lai gan uz atslēgvārdiem balstīta testēšana ir piemērota GUI automatizācijai, uz datiem balstīta testēšana ir pirmā izvēle koda testēšanai, kas veic jebkāda veida aprēķinus. Ja iepriekš esat rakstījis vienību testus, kas ir visnepatīkamākais šajos testos? Iespējams, ka jūs domājat par datiem. Jūsu testi būs pilni ar datiem, kas bieži mainās, padarot apkopi par murgu. Lai pārbaudītu dažādas kombinācijas, nepieciešami atšķirīgi dati, iespējams, padarot testus sarežģītus, neglītus zvērus.