Szegény ember BDD-je

Kicsit komolyabban megismerkedtem Cucumber BDD rendszerrel. Pontosabban elolvastam egy igen érdekes könyvet. És most már tudom miért fontos, hogy a teszt inkább olvasható legyen, mint könnyen írható.

Azelőtt nem tudtam mi is az a BDD. Most már csak majdnem nem tudom.

Kicsit összesűritve és emiatt leegyszerűsítve: Építsd fel a tesztjeidet a GIVEN-WHEN-THEN struktúra alapján, ami egy könnyen olvasható tesztesetet ad. Neked “csak” az implementációt kell mellé tenned. Ezáltal úgynevezet “executable specification”-t kapunk, ami kéz a kézben jár “Specification by Example“-vel ( könyv is van róla ).

Iskolapéldának a Cucumber-t hozzák fel, mint az egyik legjobb implementációt. Java implementáció is létezik!

De azért nem kell nagyon elszálni. Magának a BDD tesztnek a felépítésében nincs semmi különleges. A struktúrát (GIVEN-WHEN-THEN) követni kell minden teszt esetében. Az igazi váltás a szemléletben van. Végre egy módszer, kiemel egy igen fontos szempontot:

A tesztnek elsősorban olvashatónak kell lennie a könnyen írhatóság helyett.

Gondolj bele milyen sok pénzt lehet elkölteni úgynevezett teszt autómatizáló toolokra. De azok a toolok leginkább a record-replay kategóriába tartoznak.

Ha esetleg kedvet kaptál, akkor azért nem kell nagyon messzire menned. Nem kell minden áron Cucumber-t használnod. Elég ha csak a teszted belső struktúráját alakítod át egy kicsit.

A következő példa teljesen hagyomás JUnit-ban íródott.

@Test
public void user_field_empty() throws Exception {
    given_empty_user_id();
    given_user_text("otto");
    when_validate();
    then_got_error_message("User is mandatory");
}
// metódus implementációk...

Miért is jó:

• a teszt könnyen olvasható. Nincs tele “low-level” kóddal. Természetesen minden alacsonyszintű implementáció megtalálható a teszt osztályban, de nem a konkrét teszt metódusban.
• első ránézésre halvány lila gőzünk sincs, hogyan van implementálva (ami most jó, hiszen “decoupling”). Lehetséges, hogy egy service layer szintű dolgot tesztelünk, vagy egy UI-t tekerünk meg (pl) Seleniummal.
• Ugyan azt az alap-tesztet újra tudjuk használni (lásd előző pont service vs UI layer).
• Ha változik az implementáció, akkor csak a kiszolgáló metódusokat kell újraimplementálni. Maga a teszt változatlan marad.

Hát nem nagyszerű!