Miért nyüglődünk még Cucumberrel?

Nemrég egy web fejlesztési projektrõl hallottam beszámolót mind a munkát végzõ tanácsadó, mind a kliens szemszögébõl. Az egyik tanácsadó elmondta nekem, hogyan oktattak egy technológiailag visszamaradt ügyfelet agilis folyamatokra. Szerinte, habár eleinte unalmas lehet ez az ügyfélnek, idõvel értékelni fogja a tudásukat, ennek nyomán fényes, üzleti ajánlólevelek örökkön örökké érkeznek majd.

A Cucumber használatának hátrányai és széleskörü felhasználása a szegény ember integrációs tesztjeként.

Néhány nappal késõbb találkoztam az ügyféllel:egy rémálom volt dolgozni velük. Nem engedték azt, amit akartam, és jelentéktelen dolgokról való vitával pazarolták az idõmet. Habár a munkát jól végezték, nem rendelkeztek üzleti érzékkel. Nem hiszem, hogy sokáig léteznek majd.

A tanácsadó elrontotta: Többek között, nem megfelelõ folyamatot erõltettek az ügyfélre. Pláne, hogy Cucumber feature fájlokat adtak neki, hogy olvassa és fogadja el, annak ellenére, hogy ez õt nem érdekelte. Az ügyfél szavaival: mi csak egy weboldalt akartunk. (Ez valójában egy webalkalmazás volt, de a nem-technikai emberek nem tesznek különbséget). Az ügyfél csak azt akarta, mûködjön jól.

Képzeld magad az ügyfél helyébe

Lépj ki a programozói bõrödbõl egy pillanatra és tégy úgy, mintha egy elfoglalt cégtulajdonos lennél, mialatt a következõt olvasod:

A scenario-t, a feature leírás nélkül, innen vettük: You’re Cuking It Wrong . (Ne feledd, hogy Jonas (a jelzett cikk szerzõje) nem ad olvasni Cucumber fájlokat az ügyfeleinek.)

Az E-labs-os Jonas Nicklas szerint, a felsõ egy elfogadható példa a Cucumber stílusra, az érintettek nyelvén íródva. Mint egykori megrendelõje a szoftverfejlesztési szolgáltatásnak, egyet nem értésemnek kell hangot adnom. A részlet megfelelõ szintje ez:

Minden más felesleges. Ha 10 sorba telik neked, hogy közöld az aloldalak hozzáadásának módját, akkor pazarolod az idõmet. Ezzel nem vagyok egyedül. Elizabeth Keogh, BDD szakértõ, azt mondja: Ha a scenario-d azzal kezdõdik, hogy Mikor a felhasználó bepötyögi, hogy Törp a Keresés szöveg mezőbe akkor az már messze alacsony szintû. Azonban, még a Mikor a felhasználó hozzáadja a Törp-öt a kosárhoz, eljut a pénztárhoz,ezt követõen fizet a termékekért is túlságosan alacsony szintû. Valami olyasmi lesz a jó megoldás, hogy Mikor a felhasználó egy Törp-öt vásárol.

A fentiek alapján a Rails közösség túlnyomó többsége helytelenül használja a Cucumber-t. Annak ellenére, hogy másként hisszük, a legtöbb programozó soha nem írt egyetlen átvételi tesztet sem; helyette a Cucumber szintaxis használatával írtak integrációs teszteket.

A fenti elítélõ állítást úgy gondolom, bizonyítani kell. Szerzõdéses Ruby fejlesztõként és programozók munkaadójaként, megtudom erõsíteni, hogy a legtöbb feature fájl, amit láttam, step-Cucumber-ben alapértelmezésben rendelkezésre álló web step-ekbõl áll. Ezen web step-ek integrációs teszt álruhában. Mikor kitöltöm a keresés mezõt Törp-pel szerû Cucumber step-ek dominálnak a Rails közösségben, annak ellenére, hogy a legkockázatosabb megközelítésként azonosította Elizabeth Keogh.

Úgy gondoltam, hogysaját anekdotáimra épülő tapasztalat nem elég, így kutattam egy kicsit. Végigböngésztem a feature fájlokat hat nagyobb open source Rails projektben, mint például Spree-ben, Radiant-ban és a Diaspora-ban. A Tracks kivételével, szinte kizárólagosan web step-ekben lettek írva a feature fájl-jaik. Valójában integrációs teszteket írtak Cucumber szintakszist használva.

A színlelt elemző

Ügyfélként gondolva magadra, nézzük meg megint a fenti feature fájlt. Vállalkozásod üzemeltetési költségeivel teljes mértékben tisztában vagy, ennek nyomán érthetõ módon teszed fel a kérdést, hogy minek foglalkozunk annyit ezekkel a in order to dolgokkal. Miért színleli a programozó az üzleti elemzőt? Nem tudja, hogy a fejlesztési terv elfogadásával, a mögöttes üzleti értéket megértetted, és elfogadtad? És ami legfontosabb, ezt a munkát kiszámlázza neked?

A Cucumber módszere szerint leültök az ügyféllel és feature-ről, feature-re meghatározzátok, minden egyes funkció üzleti értékét. Ami szuper, de ez sok programozónak nincs benne a munkaköri leírásában. Magas szintû elemzõk és tanácsadók néha csinálják ezt, de valószínû, hogynem ilyen szerepkörben tevékenykedsz a jelenlegi projekteden, így erre a Cucumber alkalmatlan. Ezen felül, figyelembe véve a költségeit, a Cucumber használata egyenesen pazarlás.

A Cucumber használatának költsége

A Cucumber szakít a szövegszerkesztõkkel

A szövegszerkesztõk, mint a VIM, alapfeladata, hogy termelékenységünket megnöveljék. Az automatikus kiegészítés megkönnyíti a leíró metódus nevek használatát és újrafelhasználását. A fordítási ellenõrzések, mentést megelõzõen, kapnak el szintaxis-hibákat, mielõtt azok károkat okoznának. A metódus definicíók megtalálása és felhasználása egyszerûvé vált a fejlett szerkesztõ alkalmazások segítségével.

A Cucumber step-jei metódusnevek, melyek Gherkin szintaxist használva íródtak, és egyedi szintaxisuk szakítás a szövegszerkesztõkkel. A step-ek üres helyeket tartalmaznak, a paramétereket nem szabványos helyeken adják meg (When john@gmail.com has 4 unsent messages), és reguláris kifejezéseket használnak minta megadáshoz (and or). A szövegszerkesztõk nem alkalmasak ezek kezelésére, így az automatikus kiegészítés, keresés és sok más funkció megszûnik, csökkentvén a lehetséges teljesítményt.

A Cucumber-nek szüksége van saját teszt környezet fenntartására

Bárki, aki Cucumber használatát fontolgatja átvételi tesztekre valószínûleg már végez unit tesztet Test::Unit-ot vagy Rspec-et használva. Mikor a projekt komplexitása megnõ, a teszt készleteket átszervezzük úgy, hogy a megosztott teszt kódot áthelyezzük segéd metódusokba, majd több tesztfájl között megosztott modulokra. Címkézõ rendszereket használva kategorizáljuk a tesztjeinket, teszt futási idõt gyorsíthatunk például a Spork-al és watchr-t vagy autotest-et használunk tesztjeink automatikus futtatásához. Kiegészítõket adunk a teszt környezethez, hogy olyan fejlett segéd metódusokat használjunk, amelyek befagyasztják az idõt, megnyitják az e-maileket vagy webes kéréseket hamisítanak.

A Cucumber nem szeret megosztani. Nem veszi fel a meglévõ tesztkonfigurációkat vagy segéd metódusokat. A címke rendszerünknek nincs súlya és így muszáj tükröznünk a már létezõ elrendezésünket az új Cucumber világunkba. Ha fegyelmezetlenek vagyunk a refaktoring során, kódot duplikálhatunk, denormalizálva a kódbázisunkat, ha fegyelmezettek is vagyunk, növelni fogjuk projektünk bonyolultságát, és így a hibázás lehetõségét. Párhuzamosan kell fenntartanunk Cucumber-es és unit teszt-es világainkat, és a teszt kiegészítõk két úr kívánságait kell hogy lessék. A Cucumber megvámolja a közösség termelékenységét.

A Cucumber túlbonyolított útvonalválasztása

Egy technológiát nevezhetünk túlbonyolítottnak, ha termékeny használatához nagymennyiségû információ és szabály aktív ismeretére szükség van, nem egyszer az elvárható szint feletti terhelést okozván.

A Rails bonyolult. Mikor elkezdtem használni, nehéz idõszakkal néztem szembe, ahogy felfedtem az útvonalak labirintusszerû elnevezési mintáit, a többszörözéses konvenciókat, és az apró megkülönböztetéseket a különféle ActiveRecord::Base perzisztens metódusok között. Nem mondom, hogy a bonyolult rendszerek megértése rossz dolog; komplex rendszereknél ez gyakran elõfordul. Ennek viszont indokoltnak kell lennie.

A Cucumber step-ekben, egy jellegzetes weboldal említése, például a bejelentkezõ oldal, megköveteli tõlünk, hogy ezt az érintett leírást egy olyan URL-segítõ módszerhez rendeljük, amelyet alkalmazásunk ért.

A Rails útvonal választó rendszere bonyolult: Obie Fernandez szerint (The Rails Way), mindenkit, aki érti, bele lehet préselni egyetlen taxiba. A Cucumber egy absztrakciós réteget rak a már amúgy is bonyolult rendszerre, amely lassabb fejlesztéshez és több hibához vezet a nagyobb projekteken.

Új funkciók hozzáadásánál szembesültem az alábbiakkal: akaratlanul is különféle természetes nyelvi leírásokat használva írnám le az útvonalakat. Egyik nap talán a “login page” -et “the sign in page”-nek nevezném, és máskor “the log in page”-nak. Ezután a Cucumber panaszkodott, hogy nem találja a megváltozott elérési út nevet, ezért a paths.rb fájlba kellett belenéznem, hogy emlékeztessem magam az elõzõ leírásomra. Sok mindent kell fejben tartani, sok a hibák és lassulások lehetõsége.

Kísérleteztem a paths.rb fájl eltávolításával, és olyan kiegészítõ megírásával, amely humanizált URL segédek bevonásával automatikusan meghatározza az útvonalat. Elfogadhatatlan step definíciókat kaptam eredményül, mint például “And then I am on the new user session page”. Túlságosan közel jutottunk a végrehajtási nyelvhez, hogy érthetõ legyen az átlagos stakeholder számára, ezért ezt az opciót el kell kerülni, ha a Cucumber-t arra kívánjuk használni, amire szánták.

Pazarló belsõ struktúra a Cucumberben

A kedvenc Rails funkcióm az egyik legegyszerûbb: mindennek van helye. A levelezõk egy mappába mennek, a modellek egy másikba, a konfigurációk pedig valahol máshová. Feltételezve, hogy egy projekt ragaszkodik a konvencióhoz, bármelyik funkció forráskódját könnyedén megtalálhatod. Ez hatalmas termelékenységi elõnyökkel jár, különösen olyan projekteken, amelyeket más programozóktól örökölsz.

A Cucumber arra kér téged, hogy hozz létre step definíciókat minden olyan egyedi step-hez, amelyet használsz. A konvenció szerint ezeket a step-eket egy {feature_nev} _steps.rb fájl-ban kell tartani. Kisebb projekteken ez jó dolog, mivel a step definíciók könnyedén megtalálhatók. A problémák akkor kezdõdnek, amikor egyszer újra fel kell használnod jó néhány funkción keresztül a step definíciókat és TISZTÁN szeretnéd tartani a kódot. Két dolog szokott tipikusan történni:

Ha jó memóriád van, megtalálod a régi step definíciót, és újra felhasználod a metódust az új feature-ben. Ez szörnyû lépés lehet. A megosztott helperek jelenléte a promote_post_feature_steps.rb fájlban kizárólagos kapcsolatot feltételez ezzel a feature-vel. Ha késõbb eltávolítod a promote_posts feature fájlt, akkor valószínûleg eltávolítod a step definíciós fájlját is, elfelejtve, hogy globális step definíciókat is tartalmazott. Ideális esetben ezeket a megosztott step definíciókat egy globális step definíciós fájlba kellett volna átcsoportosítani, de való életben ez nem mindig történik meg. Mindenkinek vannak határidõi.

Ha nincs jó memóriád, vagy hosszú idõ eltelt, amióta utoljára láttad a projektet, akkor elfelejtheted, hogy korábban írtál egy step definíciót egy bejegyzés promóciójához. Másik lehetõség, hogy soha nem hoztál létre ilyen step definíciót, de egy másik programozó megtette, anélkül, hogy tudnád. Írsz egy új step definíciót a taxon_steps.rb fájlba, de a kódod már nem maradt TISZTA. Egy késõbbi idõpontban újratervezed a promóciós logikát, megcsinálod a változtatásokat a promote_post_feature_steps.rb-ben, és a refaktorálást befejezettnek gondolod. A taxon_steps.rb innentõl erre a step-re értelmezve elavult lesz, ez zavaró teszt futtatási hibákhoz fog vezetni, hiszen nincs alapos ok gyanakodni egy problémára, a nemrégiben refaktorált promóciós logikában. A Cucumber alapértelmezett használati módja a feature fájlok szervezésében ezekkel a nehézségekkel jár, és sok fegyelmet igényel az elkerülésük.

Terjengõs fogalmazás

Egyetértünk abban, hogy a tömörség a Ruby egyik elõnye, összehasonlítva más nyelvekkel, mint például a Java? Ugyanezen okból részesíted elõnyben a Sass-t, Coffeescript-et, és Slim-et a CSS-hez, a Javascript-hez és az ERB-hez képest? Akkor miért tartasz ki a Cucumber használata mellett?

A metódus nevek Cucumberben kétszer annyi karaktert igényelnek, mint az egyszerûbb Capybara megfelelõik. Hasonlítsd össze:

A megnövekedett terjedelem csökkenti a kifejezõképességet és teljesítményt, és hibákhoz vezet, mivel több karakter több helyet jelent, ahol elírás elõfordulhat.

A Cucumber szintaktikailag eltántorít a kód újrafelhasználásától A Cucumber felhasználók hajlamosak a step definícióikat más step definíciókkal kifejezve megadni. Az eszköz készítõi ezt azzal bátorították, hogy egyszerû megoldásokat hoztak létre ebbõl a célból. Íme egy példa:

Ez így utálatos, habár egy dolog érthetõ. A fejlesztõ azt akarja, hogy kódja TISZTA maradjon, de nem akarja a Ruby metódusokba csomagolt step definíciók hozzáadott kavalkádját. Így újra felhasználja a step definícióikat.

Megfontolandó: Amikor egy step definíción belül vagy, kizárólagosan a programozó területén tartózkodsz. A stake holder sosem olvassa ezt. Ezt észben tartva nem lenne elõnyös használni a teljes Ruby programnyelv rövidségét, pontosságát, alakíthatóságát, szerkesztõi támogatását és absztrakciós eszközeit? Ruby-t használva ilyeneket tudnál csinálni:

Véleményem szerint a fõ ok, amiért oly sok cég hagy fel az integrációs teszteléssel pár hónapon belül, az, hogy step definíciókat más step-ekben újrafelhasználnak, valamint magasabb szintû step-ek összeállítása a Cucumber alap web step-jeinek felhasználásával. A tesztjeik bonyolultak lesznek, ennek nyomán egyre kevésbé frissen tartottak.

A megoldás nem egyszerû, a legészszerûbb út magában foglalja erõteljesebb absztrakciós eszközök alkalmazását – például a teljes Ruby programnyelvet a szörnyû step definíciókkal szemben.

Konklúzió

A Cucumber-nek megvan a haszna, elsõsorban magas szintû elemzõeszközként nagy, soknyelvû projekteken. Ami azt jelenti, hogy kevés programozó dolgozik ilyen pozícióban, és a rendszeres integrációs tesztek metódus neveinek listáján kívül az átvételi tesztek pazarlásnak tûnnek. A Cucumber, amelyet a Rails programozók többsége használ, nem több, mint egy ügyetlen csomagolás az alap integrációs tesztek felett. A különbségek nem csupán kozmetikai jellegûek: a Cucumber szintaxisa költséges mind a programozó, mind az ügyfél számára, akiknek az idejük és pénzük is pazarolva van. Ráadásul a Cucumber nyílt forráskódú fejlesztésekben technikai eszközként való használata, valamint a vállalkozói munkában való felhasználása kétségtelenül nevetséges. Mégis, a programozók továbbra is helytelenül használják a Cucumber-t.

Miért nem vallod be magadnak, hogy nem végzel átvételi tesztelést, és hogy nem érzed szükségesnek projektjeidben? Cseréld le a Cucumber-t tiszta Capybara-ban végzett integrációs tesztekre, és meg fogsz lepõdni, hogy mennyivel produktívabb tudsz lenni.

Forrás: Why Bother With Cucumber Testing?