ugrás a tartalomhoz

Yadda-t használja valaki?

inf · 2016. Feb. 16. (K), 20.09
Yadda-t használja valaki? Érdekelne miben nyújt többet cucumberjs-nél. Nagyjából elmondták már fórumban, de napi tapasztalatok érdekelnének. Láttam ezen kívül, hogy vannak mocha és jasmine pluginek hozzá, de a jasmine példában azt láttam, hogy az assert lib-et használják a jasmine saját expect függvénye helyett, ami nekem fura. Akkor minek plugint írni jasmine-hez, ha egyáltalán nem is használják?
‹ Miért kellene Yeoman-t használnom? Gulp + babel + jasmine ›
 ■
1

Na közben nézem, hogy

inf · 2016. Feb. 16. (K), 20.12
Na közben nézem, hogy válaszoltak. Azt írják, hogy jasmine-ből a reportert és a test runnert használják. Az expect-et meg lehet próbálni, aztán vagy működik, vagy nem. Legrosszabb esetben chai-t be lehet importálni, ami hasonló viszont akkor megint kérdés, hogy minek a jasmine expect-et betölteni memóriába, ha közben mást használunk. Megnézem, hogy működik-e, kíváncsi vagyok. A cucumberjs-nek vannak/voltak hülyeségei, amit elvileg ez a lib javít, nekem meg igazából mindegy, hogy a gherkin alatt melyik parser fut, ha meg tudom csinálni vele azt, amit akarok. Elvileg ez jobb gherkin parser, mint a cucumberjs. Meglátjuk.
2

Mocha

Poetro · 2016. Feb. 17. (Sze), 03.10
Én mocha-val használtam egy projektben. De szerintem túl körülményes megfelelő szótárat építeni, és a teszteket kb. kétszer kell megírni. Mert meg kell írni a parsolót, és meg kell írni a tesztet.

A mocha egyébként sem tartalmaz assertion library-t, igazából akármit használhatsz rá, csak egy teszt futtató.
3

Ahm. Én úgy szoktam BDD-zni

inf · 2016. Feb. 17. (Sze), 17.40
Ahm. Én úgy szoktam BDD-zni pont emiatt, hogy parsolót nem írok, az example része kimarad, aztán megadom direkt json-ban a fixture-t. Inkább az kihívás, ha nincs hatalmas gyakorlatod, hogy hogyan állítsd össze a scenario listát meg a conversation-ökben pontosan mi legyen, amire könnyen lehet step definition-öket megadni. Olyan szempontból viszont jó, hogy dokumentációnak is elmegy kisebb módosításokkal, szemben egy TDD-vel, ahol sok esetben visszanézve azt se nagyon tudom, hogy mit teszteltem. xD A másik előnye, hogy rugalmas, ugyanarra a feature leírásra több implementáció is ráhúzható, szóval A/B tesztelsz, akkor kapásból csak step definition-t kell újraírni a másik implementáció kitesztelésének, a feature általában ugyanaz marad. Ugyanígy ha bármi más helyen implementációt cserélsz a feature marad és csak a step definition-t kell átírni. Ennyi az előnye az egész BDD-nek, hogy betesz még egy szintet, amiben leírjuk, hogy mit csinálunk, mert egy sima TDD-nél általában erről csak kevés infot adunk, és arra koncentrálunk helyette, hogy hogyan csináljuk. Én szeretem a BDD-t, sokkal jobban, mint a TDD-t, bár kétségkívül több a munka vele. :-)

Egyébként example parsolásnál elvileg újrahasznosíthatóak dolgok. Van a yaddában valami define függvény, aminél meg lehet adni, hogy melyik változót hogyan parsoljuk.
Talán érdemes lehet az egészet kiszervezni egy külön libbe mondjuk yadda example parsers néven. Érdeklődök, hátha van ilyen, vagy ha nem, akkor megkérem őket, hátha beveszik feature requestnek.
Elvileg maga a szöveges része a dolognak meg generáltatható többé-kevésbé a conversation-ök alapján. Nyilván a szövegből a változókra vonatkozó részt manuálisan kell átírni.
Szóval ez a hiányossága a BDD-nek inkább arról szól, hogy eszközökben van hiány, ami pótolható. Már ha van ideje rá valakinek.
4

No azt írják, hogy van ilyen:

inf · 2016. Feb. 17. (Sze), 20.27
No azt írják, hogy van ilyen: https://github.com/simoami/mimik ha step definition skeletont akarsz generáltatni feature leírások alapján. A variable parser-es, converter-es részre még úgy néz ki, hogy nincs külön lib, arra majd lehet, hogy összeszórok gyorsan valamit, mondjuk xsd típusokból kiindulva, hogy ne kelljen már minden regex patternt kézzel megadni.
5

úgy néz ki, hogy nincs külön

Poetro · 2016. Feb. 17. (Sze), 20.34
úgy néz ki, hogy nincs külön lib, arra majd lehet, hogy összeszórok gyorsan valamit, mondjuk xsd típusokból kiindulva, hogy ne kelljen már minden regex patternt kézzel megadni

Na ez az a része a BDD-nek ami számomra a fájdalmat okozza. De pl. Chai BDD style már sokkal barátságosabb. A magyarázatokat pedig a tesztek és a teszt sorozatok nevében adom meg.
6

Ja jasmine is hasonló, de

inf · 2016. Feb. 17. (Sze), 20.55
Ja jasmine is hasonló, de nekem ez nem BDD. Nincs szétválasztva benne a feature description és a teszt implementáció, ami a feature implementációjához (a kódhoz, amit írsz) illik. Egy gherkin alapú dolognál ki tudod nyomtatni egy az egyben a feature descriptiont, úgy, hogy egy szó nem esett még a teszt vagy a feature implementációról. Jasmine-nál ez esélytelen, csak részben generáltatható a tesztek alapján a feature description. Ez gond, mert először a feature descriptiont kellene megírni és az alapján csinálni a teszt implementációt, a teszt implementáció alapján meg a feature implementációt. Jasmine-nál borul a sor, először megírod a teszt implementációt, aztán utána a feature implementációt, és esetleg generáltathatsz feature description szerű dolgot, pl olyasmit, mint amit a jasmine reporter ad. Ugye itt behavior driven developmentről és nem test driven developmentről beszélünk, hát a jasmine ezek alapján erősen test driven. Ezt szóvá is tettem a jasmine fejlesztőinél, hogy nem BDD, hanem TDD a keretrendszerük, és miért állítanak róla valótlant, de láthatóan nem fogták fel, hogy miről beszélek.

Egyébként yaddának van jasmine pluginje is, mint már írtam. Ez pótolja a behavior driven-es részt az egyenletből, mert a feature description-ök alapján tölti ki a describe() és it() függvényeket. Szóval ha BDD-zek, akkor jasmine-t csak yaddával együtt használom ezentúl. Még agyalok, hogy fogok e külön TDD-zni ezek után, mert nekem az jött le, hogy alacsonyabb szinten is használható a BDD, bár sokan nem ajánlják.

Tetszik nekem ez a mocha + chai is, amit írtál. Lehet, hogy áttérek rá. Mocha-t már néztem évekkel ezelőtt, de akkor nem sikerült telepíteni valami miatt, azért jasmine mellett döntöttem. Gondolom ez azóta változhatott.
7

Neked sikerült belőni

inf · 2016. Már. 7. (H), 14.20
Neked sikerült belőni browserify-al vagy webpack-el? A default feature fájl keresője nem igazán akar működni böngészőben, valami fs hibát ír. Tudtommal fs működik browserify-ban is, úgyhogy nem igazán értem mi a kínja. Mások xhr-el meg jquery gettel workaroundolják a problémát, amit biztos nem követek el.
8

Nem használtam egyiket sem.

Poetro · 2016. Már. 7. (H), 16.29
Nem használtam egyiket sem.
9

Ok. Ezek szerint böngészőben

inf · 2016. Már. 7. (H), 17.41
Ok. Ezek szerint böngészőben még nem megoldott nála a tesztek futtatása.
10

Forkoltam azt beletákoltam.

inf · 2016. Már. 12. (Szo), 05.09
Forkoltam azt beletákoltam. https://github.com/inf3rno/yadda/commit/3b14ab5f407c705e08bc2462e77ec72b012e9ab9 Elvileg nem sokára benne lesz a rendes projektben is, nem csak ebben a forkban.