Kezdjük a gonoszabb részével a dolgoknak, méghozzá azzal, hogy a fenti rendszer tervezőjének bár volt annyi esze, hogy ne "double forintÖsszeg" jellegű felületet írjon, hanem alkalmazta a csodálatos Money tervezési mintát, ami ugye azért kell, hogy a átváltogatásokat, meg a tzedeseket meg hasonlókat kezelő logika egy helyen legyen (pl most a ForintÖsszeg osztályban), de fel nem merült benne, hogy ugyanezt érdemelnék a dátum intervallumok is. Pedig ez a hiba jó eséllyel elő nem fordulhatott volna, ha a fenti metódus mondjuk úgy néz ki, hogy
ForintÖsszeg kamatSzámítóMetódus(DátumIntervallum intervallum, ForintÖsszeg forintÖsszeg).
Mondjuk nehéz is elhinni, hogy egy ilyen rendszerben a kamatszámító metódus az egyetlen, ahol két dátum mint egy intervallum fordul elő. És akkor már el is lehet mondani azt, hogy a TDD-nek lett volna esélye megakadályozni a fenti problémát: például azzal, hogy a refaktorálás szakasznál rájön szépen Pali, hogy már harmadszor írja le ugyanazt, azaz hogy Dátum intervallumKezdete, Dátum intervallumVége, és következetesen végrehajtja az "eliminite duplication" nevű igen hasznos lépést.

Aztán persze az is igaz, hogy némileg félreértjük egymást, azzal kapcsolatban, hogy mit nevezünk egységtesztnek, ami nem meglepő, mert ez egy globális jelenség, a szakma angol anyanyelvű része is ezen izgulászik:
http://www.infoq.com/news/2008/06/hill-microtesting
Amikor én egységteszteket mondok, akkor ezekre a mikrotesztekre gondolok, amik nem piszkálnak adatbázist, fájlrendszert, más relatíve lassú erőforrást, és az egységeket önmagukban tesztelik, nem pedig a kollaborátoraikkal. Ezeket a fejlesztőnek kell megírnia, hisz arról szól a dolog, hogy ezeket minden egyes kódváltoztatásnál le kell futtatni. Ezek nélkül nem lehetséges megbízhatóan refaktorálni, tehát a kód belső minőségét állandóan, és megbízhatóan javítani.
A mikrotesztek rendszerint nem tesztelik az egyes egységek együttműködését, tehát szigorú értelemben véve esélyük nincs elkapni a fenti hibát.

Az egyes modulok együttműködését az integrációs teszteknek kell vizsgálnia, azaz a fenti esetben pl egy olyan, szintén junit tesztesetként megfogalmazható tesztnek, ami a kliens kódot és a kamatszámító kódot egyszerre teszteli. Ha a két fél nem ugyanúgy gondolkozik a paraméterek sorrendjéről, az Pali kommitja után mondjuk egy órával kiderül, amikorra a kontinyusz integrésön szerver lefuttatta az összes integrációs tesztet. Meg acceptance tesztet. Vagy ha nem kommit után rögtön, akkor mondjuk éjszaka. Vagy minden kedden meg csütörtökön.
De az, hogy az egységteszt utáni következő minőségellenőrzési réteg az ÁTADÁS UTÁNI, felhasználó általi tesztelés, az szégyen, és nem annyira Palira nézve.

@fqqdk: Kösz a kommentet, nagyon fontos gondolatokat pedzegetsz. Bár sok olyasmire hivatkozol, ami nincs is benne a bejegyzésben azért érdemes elgondolkodni ezeken a felvetéseken.

Való igaz, hogy jól tervezett interfészeket jobban lehet tesztelni. Ha a megrendelő rendszerébe beleillő kódot kell készíteni, akkor ezek az interfészek adottak.

Ettől még a unit teszt, ami az én fejemben is pontosan az, amit te is leírsz még ki deríthette volna a hibát. Nem integrációs volt a probléma, nem az volt a gond, hogy másképp hívták meg a modult, mint ahogy azt kellett volna. Pontosan úgy lett meghívva, mint ahogy az definiálva volt. Csak nem úgy működött.

A mikrotesztnek igenis van esélye elkapni a fenti hibát, ha csak nem tartalmazza a mikroteszt kód is ugyanazt a hibát, mint a tesztelt kód. Aminek, mint látjuk van esélye, ha ugyanaz írja a mikrotesztet, mint a kódot. És még akkor is, ha nem ugyanaz írja.

Mivel nem a projekt részletes leírása volt a cél, ezért a blogból nem derült ki, de jelen esetben az átadás után a funkcionális tesztelés, az általunk szállított kód funkcionális tesztelését jelentette, ami kb. megfelel annak az integrációs tesztnek amit leírsz a kommentedben. Csak azt éppen nem mi végeztük, hanem a fővállalkozó (számunkra megrendelő, de nem ügyfél), aki, ellentétben velünk rendelkezett is az által írt és a mi kódunkkal integrálandó kóddal.

Nil sine labore. Hiba se.

A bejegyzésben kijavítottam a funkcionálist integrációsra, mert valóban nem jó szó a konkrét esetben funkcionális tesztről beszélni.

Én már csak ilyen troll vagyok, a tények soha nem állnak a véleményem útjába. :)

@Verhás Péter: oooppsss
>számunkra megrendelő, de nem ügyfél

Hogy ne lenne ügyfél!!! Helyesen

számunkra megrendelő, de nem felhasználó

Erről egy dolog jutott eszembe, ami nagyon tetszett ezzel kapcsolatban. A unit teszteket lehet dokumentációs célokra használni. Ez kicsit hasonlít ahhoz a felfogáshoz, hogy nem kell részletes dokumentáció, mert a program a legteljesebb, legjobban leíró és legfrissebb dokumentáció (csak beszédes neveket használj). E mentén a unit tesztel meg dokumentálhatod, hogy milyen bemenetre milyen kimenetet várunk el. Nem tudom, hogy van-e erre automatizmus, ezt kigenerálni olvashatóbb formátumban.

@Viczi testdox.codehaus.org/