A legalapvetőbb szinten az Exercism lényegében a tesztekről és a tesztelésről szól: ez viszi előre a megvalósításodat, és ez jelzi, amikor egy feladat elkészült.
Azonnali visszajelzés
A Pharo kiválóan támogatja a tesztekkel való munkát, sőt a fokozatos tesztelést is! Bármelyik tesztet lefuttathatod egy feladathoz, ha a teszteset-osztály vagy -metódus melletti gömböcskére kattintasz.
A tesztgömböcskék színe az utolsó tesztfuttatás eredményétől függ:
- zöld, ha a teszt sikeres
- sárga, ha egy állítás megbukik
- piros futásidejű hiba vagy kivétel esetén
Rendezett tesztek
Az Exercism feladataiban a teszteket szándékosan megszámozták, hogy meghatározott végrehajtási sorrendet adjanak nekik (pl. test01_verifySomeProperty, test02_verifyAnotherProperty stb.).
Amikor egy feladaton dolgozol, érdemes rákattintanod az első teszt gömböcskéjére, megértened, miért bukik el, és mit kell tenned, hogy sikerüljön, majd beírnod a megoldásodba a kódot, hogy működjön. A Pharo-ban teljesen megszokott, hogy ezeket a változtatásokat a debuggerben végzed el, ahol egyszerre férsz hozzá a kódszerkesztőhöz és az összes változó és paraméter nézetéhez, ami segít megérteni a problémát.
MEGJEGYZÉS: Nem bevett gyakorlat a teszteket sorrendjelző előtaggal ellátni, és ezt a saját projektednél NE is tedd.
Hibás kóddal is fut
A Pharo gond nélkül fut hibás kóddal is, és a debugger egyszerűen újra megnyílik, amikor hibába ütközik (legyen az szintaktikai hiba, hibás érték, vagy akár egy hiányzó osztály vagy metódus). Ez a technika nagyban hozzájárult a tesztvezérelt fejlesztés megszületéséhez, és te is belekóstolhatsz ebbe a megközelítésbe, ha megpróbálod lefuttatni bármelyik feladat első tesztjét. A debugger azonnal jelzi, hogy nem találja a megoldásod osztályát (hiszen még nem írtál semmit). Kényelmes módon van egy „Create” gomb, amivel hozzáadhatod a hiányzó osztályt, és folytathatod a futtatást, amíg az be nem fejeződik, vagy újabb hibába nem ütközik.
Az első tesztnél aztán egy második hibába futsz bele, mert még egyetlen metódust sem írtál. A debugger „Create” gombja ismét segít definiálni egyet, és folytathatod a futtatást. Ekkor a hívási láncban lejjebb is kattinthatsz, átnézheted a megbukott teszt követelményeit, és módosíthatod az új metódusodat, hogy sikerüljön.
Szeresd a debuggert
A fejlesztés későbbi szakaszában hasznos lehet, ha a veremben hátrébb kattintasz, és a „Restart” gombbal egy korábbi ponttól folytatod a program végrehajtását; így aztán lépésenként végigmehetsz a programon, és megnézheted, mi történik. Ez fontos és hasznos módja annak, hogy megértsd, miért nem működik a programod.
A változókon kívül a debuggerben bármelyik utasítást kijelölheted, és az inspect/print segítségével megnézheted a kiértékelés eredményét. Ez akkor lehet hasznos, amikor egy metódus eredményét teszteled, vagy amikor egy objektum belső állapotát vizsgálod.
Ne felejtsd el, hogy a debuggerben futó kódot is módosíthatsz, és a mentés egyszerűen újraindítja a végrehajtást abban a metódusban, amelyet épp mentettél. Így kísérletezhetsz a változtatásokkal, és még „a pillanatban” láthatod az eredményeiket.
Összefoglalva: ne félj használni a Pharo debuggerét, mi értékes eszköznek tartjuk, amely segít megérteni és kipróbálni egy problémát.
Nagyobb tesztcsoportok és automatizálás
Ha valaha nagyobb tesztcsoportokat kell futtatnod, azokat a Package menüből is elindíthatod, illetve használhatod a Test Runner eszközt is (a World menüből érheted el, vagy beírhatod ezt: <meta> + OU).
A teszteket a playgroundból programozottan is futtathatod, ha kiértékeltetve kiíratod:
AllExercismTests suite run.
Ha többet szeretnél megtudni a tesztek belső működéséről, olvashatsz a SUnitról, vagy böngészheted a kódot a TestCase osztályhierarchiában.
Tudtad? A TDD-t a Smalltalkban találták fel a SUnit tesztkönyvtár bevezetésével
