Vlákno názorů k článku Behavior-driven development v Pythonu s využitím knihovny Behave od ivoszz - Chtěl jsem to napsat už u toho popisu...
-
Chtěl jsem to napsat už u toho popisu u Clojure. Kdysi jsem si Gherkin v rámci kurzu Ruby zkoušel (docela dost, byly to desítky testů) a i když to na první pohled vypadá bombasticky, nejsem si jist, že všechna ta práce kolem navíc vyváží zlepšenou čitelnost pro laiky. Testy stejně většinou píší programátoři a není problém je uvést scénářem. Výsledek je velice podobný, pokud se dodrží určitá kultura. Osobně dávám přednost stručným table testům, tak jak se používají v Go. Když se udělají dobře, jsou jednoduché a přehledné. Nakonec i jednoduché BDD frameworky ve stylu Jasmine/Mocha jsou docela přehledné. A to, že se Gherkin příliš nerozšířil, to podle mne jen potvrzuje.
-
ceckar (neregistrovaný)
Ono asi záleží na konkrétním jazyku. Ruby u nás prakticky nepoužíváme, tak nevím, ale třeba pro Javu je Gherkin/Cucumber mnohem lepší, než se snažit lidem s doménovou znalostí nacpat přímo zdrojáky s testy. Protože ti lidi Javu znají maximálně tak že ji brali na škole v jednom semestru.
To se bavím hlavně o backendu, frontend jde bohudík ḿimo mě :-) Ale mrknul jsem na ten Mocha a i když JS znám, tak je to stále dost nečitelný (z wiki):
var assert = require("assert") describe('Foo', function(){ describe('#getBar(value)', function(){ it('should return 100 when value is negative') // placeholder it('should return 0 when value is positive', function(){ assert.equal(0, Foo.getBar(10)); }) }) })U Cucumberu, pardon Gherkinu je pěkný i to, že když už test spadne, je přesně jasnej řádek, takže to dohledá i associate QA a dokáže se zorientovat co a jak.
-
Pavel Tišnovský (neregistrovaný)
řekl bych, že strašně záleží na konkrétním způsobu použití. Pokud je celý tým a projekt konzistentní, tedy psaný v jednom nebo dvou jazycích (dva pro typickou webovku), tak nemusí být výhoda DSL tak zřejmá. Ve chvíli, kdy je to projekt založený na mikroslužbách (a třeba u nás je každá psaná v něčem jiném), tak to integrovat přes DSL, třeba zrovna přes Gherkin, mi připadne jako fajn řešení. Ale možná je to tím, že mám rád dobře navržené DSL a Gherkin do této skupiny IMHO patří :-)
-
Whyki (neregistrovaný)
Gherkin se prave snazi bojovat se situaci kdy vetsinu testu pisi programatori, cilem je umoznit sirsimu osazestvu definovat testy, precist si co za testy existuje a vymyslet co neni pokryto atd. Zkratka udelat test specifikaci pristupnou vice lidem, napriklad tem co definuji jak by produk mel fungovat v pripade ze nejde o developera.
-
Pavel TišnovskýZlatý podporovateljj je pravda, že je tam nějaká práce navíc, ale řekl bych, že ve chvíli, kdy je testovaný "stavový prostor" velký, se už ta investice vyplatí. Příkladem může být, když se napíše testovací krok s 2-3 proměnnými; takový krok se klidně v testech může volat 10x-100x, a takovéto testy dokážou napsat i lidi, kteří to nemají v hlavním popisu práce.
U nás je tým rozdělen asi trošku netypicky - jedno QA na cca 15-20 vývojářů (pořád to trošku rotuje :-). A ti vývojáři píšou různé části aplikace: front end, back end, datové pumpy apod., je tam spousta API a celé je to dost složité. Takže role QA je udělat kostru pro BDD, tj. napsat ty jednotlivé kroky. A vývojáři sami jsou potom na základě change requestů schopni rozšířit .features bez nutnosti znát "střeva" kroků. Tady Gherkin udělá svoji práci, protože na .feature dokáže šáhnout jak skalní front-endista, tak i back-endista nebo člobrda se znalostí domény a již řekněme menší znalostí programování :-)
ČLÁNKY DO MAILU