Prvý testovaný vývoj s FitNesse

Počas posledných niekoľkých rokov som pracoval vo všetkých rolách testovacieho procesu, používal som serverový JavaScript, Perl, PHP, Struts, Swing a architektúry založené na modeloch. Všetky projekty sa líšili, ale všetky mali určité spoločné črty: termíny sa oneskorili a projekty ťažko dosiahli to, čo zákazník naozaj potrebné.

Každý projekt mal nejakú požiadavku, niekto bol veľmi podrobný, niekto mal iba pár strán. Tieto požiadavky zvyčajne prešli tromi fázami:

• Boli napísané (buď zákazníkom, alebo dodávateľom) a dostali určitý oficiálny súhlas
• Testéri sa snažili s požiadavkami pracovať a považovali ich za viac-menej neadekvátne
• Projekt vstúpil do fázy akceptačného testovania a zákazník si zrazu spomenul na všetky možné veci, ktoré softvér potreboval urobiť dodatočne / inak

Posledná fáza viedla k zmenám, ktoré viedli k zmeškaným termínom, čo kládlo dôraz na vývojárov, čo následne viedlo k ďalším chybám. Počet chýb začal rýchlo stúpať a celková kvalita systému klesala. Znie to povedome?

Uvažujme, čo sa pokazilo vo vyššie popísaných projektoch: Zákazník, vývojár a tester nespolupracovali; odovzdali požiadavky ďalej, ale každá rola mala iné potreby. Okrem toho vývojári zvyčajne vyvíjali akési automatizované testy a testéri sa tiež snažili automatizovať niektoré testy. Zvyčajne nedokázali dostatočne koordinovať testovanie a veľa položiek bolo testovaných dvakrát, zatiaľ čo iné (zvyčajne tvrdé časti), vôbec. A zákazník nevidel žiadne testy. Tento článok popisuje spôsob riešenia týchto problémov kombináciou požiadaviek s automatizovanými testami.

Zadajte FitNesse

FitNesse je wiki s niektorými ďalšími funkciami na spustenie testov JUnit. Ak sú tieto testy kombinované s požiadavkami, slúžia ako konkrétne príklady, čím sa požiadavky ešte viac objasňujú. Ďalej sú testovacie údaje logicky usporiadané. Najdôležitejšou vecou pri používaní aplikácie FitNesse je však nápad za tým to znamená, že sa ukázalo, že požiadavky sú napísané (čiastočne) ako testy, vďaka čomu sú testovateľné, a preto je ich splnenie overiteľné.

Použitím FitNesse môže vývojový proces vyzerať takto: Inžinier požiadaviek zapíše požiadavky do FitNesse (namiesto Wordu). Snaží sa čo najviac zapojiť zákazníka, ale to zvyčajne nie je možné dosiahnuť každý deň. Tester opakovane nakukne po dokumente a od prvého dňa kladie zložité otázky. Pretože tester uvažuje inak, nemyslí si: „Čo urobí softvér?“ ale "Čo sa môže pokaziť? Ako to môžem zlomiť?" Vývojár myslí skôr na inžiniera požiadaviek; chce vedieť: „Čo musí softvér robiť?“

Tester začne svoje testy písať skôr, keď požiadavky ešte nie sú splnené. A zapisuje ich do požiadaviek. Testy sa stávajú súčasťou nielen požiadaviek, ale aj procesu kontroly / akceptácie požiadaviek, ktorý má niektoré dôležité výhody:

• Zákazník uvažuje aj o testoch. Väčšinou sa na ich tvorbe dokonca podieľa (mohli by ste byť prekvapení, koľko zábavy s tým dokáže zažiť).
• Špecifikácia sa stáva oveľa podrobnejšou a presnejšou, pretože testy sú zvyčajne presnejšie ako obyčajný text.
• Skoré premýšľanie o skutočných scenároch, poskytnutie testovacích údajov a výpočet príkladov vedie k oveľa jasnejšiemu pohľadu na softvér - napríklad k prototypu, iba s ďalšími funkciami.

Nakoniec sa požiadavky odovzdajú vývojárovi. Teraz má ľahšiu prácu, pretože je menej pravdepodobné, že by sa špecifikácia zmenila, a to kvôli všetkým zahrnutým príkladom. Pozrime sa, ako tento proces uľahčuje prácu vývojárom.

Implementácia najskôr na skúšku

Najťažšou časťou spustenia vývoja test-first je zvyčajne to, že nikto nechce tráviť toľko času písaním testov, až potom musí nájsť spôsob, ako dosiahnuť ich fungovanie. Pomocou postupu opísaného vyššie dostane vývojár v rámci svojej zmluvy funkčné testy. Jeho úlohy sa zmenia z „Vyrobte si to, čo chcem, a vy ste hotoví, kým nepreskúmam vašu prácu a neurobíte zmeny“ na „Nechajte tieto testy fungovať a máte hotovo.“ Teraz majú všetci lepšiu predstavu o tom, čo majú robiť, kedy majú byť práce dokončené a kde stojí projekt.

Nie všetky tieto testy budú automatizované a všetky nebudú jednotkové. Testy zvyčajne rozdelíme do nasledujúcich kategórií (podrobnosti budú nasledovať):

• Testy založené na dátach, ktoré je potrebné implementovať ako jednotkové testy. Typickým príkladom sú výpočty.
• Testy založené na kľúčových slovách, ktoré automatizujú použitie aplikácií. Toto sú testy systému a vyžadujú spustenie aplikácie. Klikne sa na tlačidlá, zadajú sa údaje a skontroluje sa, či výsledné stránky / obrazovky obsahujú určité hodnoty. Testovací tím zvyčajne implementuje tieto testy, ale profitujú z nich aj niektorí vývojári.
• Ručné skúšky. Tieto testy sú buď príliš nákladné na automatizáciu, a možné chyby nie sú dostatočne závažné, alebo sú také zásadné (úvodná stránka sa nezobrazí), že by bolo možné zistiť ich poškodenie naraz.

Keď som v roku 2004 prvýkrát čítal o FitNesse, zasmial som sa a povedal som, že to nikdy nepôjde. Myšlienka napísať moje testy na wiki, ktorá ich automaticky premenila na testy, sa zdala príliš absurdná. Ukázalo sa, že som sa mýlil. FitNesse je skutočne tak jednoduchý, ako sa zdá.

Táto jednoduchosť začína inštaláciou. Stačí si stiahnuť úplnú distribúciu FitNesse a rozbaliť ju. V nasledujúcej diskusii predpokladám, že ste rozbalili distribúciu na C: \ fitnesse.

Spustite program FitNesse spustením run.bat (spustiť.sh v systéme Linux) skript v C: \ fitnesse. FitNesse štandardne prevádzkuje webový server na porte 80, ale pridaním môžete určiť iný port, povedzme 81 -p 81 na prvý riadok v dávkovom súbore. To je všetko; teraz môžete získať prístup k aplikácii FitNesse na adrese // localhost: 81.

V tomto článku používam Java verziu FitNesse pre Windows. Príklady však možno použiť aj pre iné verzie (Python, .Net) a platformy.

Niektoré testy

Online dokumentácia spoločnosti FitNesse poskytuje niekoľko jednoduchých príkladov (porovnateľných s neslávne známym príkladom peňazí od JUnit), ktoré vám pomôžu začať. Sú v poriadku, keď sa naučia používať FitNesse, ale nie sú dostatočne komplikovaní na to, aby presvedčili niektorých skeptikov. Preto použijem príklad z reálneho sveta z jedného z mojich nedávnych projektov. Problém som výrazne zjednodušil a kód, ktorý nebol prevzatý priamo z projektu, bol napísaný na ilustračné účely. Tento príklad by však mal byť dostatočne komplikovaný, aby demonštroval silu jednoduchosti FitNesse.

Predpokladajme, že pracujeme na projekte, ktorý implementuje komplexný podnikový softvér založený na prostredí Java pre veľkú poisťovňu. Produkt zvládne celé podnikanie spoločnosti vrátane správy zákazníkov a zmlúv a platieb. Pre náš príklad sa pozrieme na malú časť tejto aplikácie.

Vo Švajčiarsku majú rodičia nárok na jeden prídavok na dieťa. Tento príspevok dostávajú iba za splnenia určitých okolností a ich výška sa líši. Nasleduje zjednodušená verzia tejto požiadavky. Začneme s „tradičnými“ požiadavkami a potom ich presunieme do spoločnosti FitNesse.

Existuje niekoľko fáz prídavkov na deti. Nárok sa začína prvým dňom mesiaca, v ktorom sa dieťa narodí, a končí sa posledným dňom mesiaca, v ktorom dieťa dosiahne vekovú hranicu, skončí svoju učňovskú školu alebo zomrie.

Po dosiahnutí veku 12 rokov sa nárok zvyšuje na 190 CHF (oficiálny symbol meny Švajčiarska) počnúc prvým dňom mesiaca narodenia.

Zamestnanie rodičov na plný a čiastočný úväzok vedie k rôznym nárokom, ako je to podrobne uvedené na obrázku 1.

Aktuálna miera zamestnanosti sa počíta z aktívnych pracovných zmlúv. Zmluva musí byť platná. Ak je stanovený dátum ukončenia, musí byť uzavretá v „aktivačnom období“. Obrázok 2 ukazuje, na koľko peňazí má rodič nárok, v závislosti od veku dieťaťa.

Predpisy, ktoré upravujú tieto platby, sa upravujú každé dva roky.

Pri prvom prečítaní môže špecifikácia znieť presne a vývojár by mal byť schopný ľahko ju implementovať. Sme si však skutočne istí okrajovými podmienkami? Ako by sme testovali tieto požiadavky?

Scenáre môžu byť skvelým pomocníkom pri hľadaní výnimiek a okrajových podmienok, pretože poskytujú dobrý spôsob, ako presvedčiť odborníkov na domény, aby hovorili o podnikaní.

Scenáre

U väčšiny projektov odovzdá technik požiadaviek špecifikáciu vývojárovi, ktorý požiadavky preštuduje, položí niekoľko otázok a začne s návrhom / kódovaním / testovaním. Potom vývojár odovzdá softvér testovaciemu tímu a po niekoľkých úpravách a opravách ho odovzdá zákazníkovi (ktorý pravdepodobne bude myslieť na niektoré výnimky vyžadujúce zmeny). Presunutie textu do FitNesse tento proces nezmení; pridanie príkladov, scenárov a testov však bude.

Scenáre sú obzvlášť užitočné na rozbalenie lopty počas testovania. Nasleduje niekoľko príkladov. Odpoveď na otázku, koľko sa má vyplácať každý príspevok na dieťa, veľa objasní:

• Mária je osamelý rodič. Má dvoch synov (2 roky Bob a 15 rokov Peter) a pracuje na čiastočný úväzok (20 hodín týždenne) ako sekretárka.
• Mária príde o prácu. Neskôr pracuje 10 hodín týždenne ako predavačka v obchode a ďalších 5 hodín ako opatrovateľka.
• Paul a Lara majú dcéru (Lisa, 17), ktorá je fyzicky postihnutá, a syna (Frank, 18), ktorý je stále na univerzite.

Samotný rozhovor cez tieto scenáre by mal pomôcť procesu testovania. Ich manuálne spustenie v softvéri takmer určite nájde nejaké voľné konce. Myslíte si, že to nemôžeme urobiť, keďže ešte nemáme prototyp? Prečo nie?

Testovanie na základe kľúčových slov

Na simuláciu prototypu je možné použiť testovanie pomocou kľúčových slov. FitNesse nám umožňuje definovať testy riadené kľúčovými slovami (ďalšie podrobnosti nájdete v časti „Automatické testovanie založené na údajoch“). Aj keď žiadny softvér (automaticky) nevykonáva testy, testy založené na kľúčových slovách veľmi pomôžu.

Obrázok 3 zobrazuje, ako by mohol vyzerať test založený na kľúčových slovách. Prvý stĺpec predstavuje kľúčové slová od spoločnosti FitNesse. Druhý stĺpec predstavuje metódy v triede Java (tie píšeme a musia dodržiavať obmedzenia kladené na názvy metód v Jave). Tretí stĺpec predstavuje údaje zadané do metódy z druhého stĺpca. Posledný riadok demonštruje, ako môže vyzerať neúspešný test (zložené testy sú zelené). Ako vidíte, je celkom ľahké zistiť, čo sa pokazilo.

Takéto testy sa vytvárajú ľahko a dokonca zábavne. Môžu ich vytvoriť testeri bez programátorských schopností a zákazník si ich môže prečítať (po krátkom úvode).

Definovanie testov týmto spôsobom, hneď vedľa požiadavky, má oproti tradičnej definícii testovacích prípadov niektoré dôležité výhody, a to aj bez automatizácie:

• Kontext je na dosah ruky. Samotný testovací prípad je možné napísať s čo najmenším počtom práce a je stále presný.
• Ak sa požiadavka zmení, existuje veľká šanca, že sa zmení aj test (nie je to veľmi pravdepodobné, ak sa použije niekoľko nástrojov).
• Test je možné vykonať naraz, aby sa ukázalo, čo je potrebné opraviť, aby táto nová / zmenená požiadavka fungovala.

Na automatizáciu testu sa vytvorí tenká vrstva softvéru, ktorý sa deleguje na skutočný testovací kód. Tieto testy sú obzvlášť užitočné na automatizáciu manuálnych testov GUI. Na automatizáciu testovania webových stránok som vyvinul testovací rámec založený na HTTPUnit.

Tu je kód automaticky vykonaný spoločnosťou FitNesse:

balíček stephanwiesner.javaworld;
import fit.ColumnFixture;
verejná trieda ChildAllowanceFixture rozširuje ColumnFixture {public void personButton () {System.out.println ("stlačenie tlačidla osoby"); } public void securityNumber (int number) {System.out.println ("zadanie securityNumber" + číslo); } public int childAllowance () {System.out.println ("výpočet prídavku na dieťa"); návrat 190; } [...]} 

Výstup testov je možné preskúmať aj vo FitNesse (pozri obrázok 4), čo veľmi pomáha pri ladení. Na rozdiel od JUnit, kde je človek odradený od písania ladiacich správ, považujem ich pri práci s automatizovanými webovými testami za absolútne nevyhnutné.

Pri testovaní webovej aplikácie sú na stránke FitNesse zahrnuté a zobrazené chybové stránky, vďaka čomu je ladenie oveľa jednoduchšie ako pri práci so súbormi denníka.

Testovanie na základe dát

Zatiaľ čo testovanie pomocou kľúčových slov je pre automatizáciu grafického používateľského rozhrania v poriadku, testovanie založené na dátach je prvou voľbou pre testovanie kódu, ktorý umožňuje akýkoľvek druh výpočtu. Ak ste už predtým písali jednotkové testy, čo je na nich najviac nepríjemné? Je pravdepodobné, že myslíte na dáta. Vaše testy budú plné údajov, ktoré sa často menia, takže údržba sa stáva nočnou morou. Testovanie rôznych kombinácií vyžaduje rôzne údaje, pravdepodobne budú vaše testy komplikované a škaredé.