Názory k článku Behavior-driven development v Pythonu s využitím knihovny Behave

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.

jj to je asi nejdůležitější rozdíl. Asi jsem měl různé přístupy k BDD zmínit na začátku článku. No nestalo se, to se omlouvám, zkusím to dopsat příště.

ř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ří :-)

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.

Co se s testem stane, když se testovaná metoda přejmenuje z "add" na něco konkrétnějšího (běžná součást vývoje)? Zvládne vývojové prostředí přejmenovat i metodu v testu napsaném v úplně jiném jazyce? Nebo ruční práce "tak dlouho opravuji, až to zase začne fungovat"?

Typicky je v IDE naimportován celý projekt, a to včetně adresáře "features/steps", takže s tím dokáže prostředí dělat to, co s dalšími moduly (ale samozřejmě zdaleka neznám všechna IDE pro Python, jen klasiku PyCharm a spol.)

A zvládne tedy Pycharm přejmenovat po změně názvu metody kód v Gherkinu i copy/paste texty v té anotaci?

Nee, do těchto dvou částí nešahá a IMHO by asi ani neměl (je to změna chování aplikace?).

Docela dobra vec je v na zacatku napsat mock objekt nad kterym napisu prvni sadu failujicich testu. Protoze mock objekt bude pythoni proxy, je jednoduche prehodit jmeno metody v jednom miste.

Nicmene to je reseni problemu ktery vznikne vzdycky kdyz musis refactorovat.

Prohlédl jsem to jen zběžně,tak kdyžtak pardon..
V čem je výhoda behave,než si napsat unittesty?

Je pravda ze se hodne pouzivaji na Akceptacni testy, ktere obvykle definuje nekdo jiny nez developer. Ale neznamena to ze nemuzete stejnym spusobem psat unittesty. Oproti unittestum to nema zadnou vyhodu, krome jednoduche citelnosti a toho ze popis/definice testu je i zaklad dokumentace testu a je z nej jasne co je a co neni otestovano (to spousta lidi u unittestu zanedbava).

BDD se používají na jiné úrovni než unit testy a taky je typicky píše někdo jiný z týmu (někdy je upravuje přímo zákazník se znalostí domény). Zatímco unit testy si píšou (ok měli by psát :-) sami vývojáři a jsou součástí běžných změn (v syncu se změnami v kódu), tak BDD scénáře popisují chování systému například na úrovni business logiky.

Ten příklad s add byl blíž k úrovni unit testů (aby se ukázaly základní možnosti jazyka Gherkin), ale názornější budou další příklady založené například na testování REST API nebo web UI se Seleniem. Nebo vůbec obecný popis logiky, který se nijak těsně neváže na kód, ale pouze na očekávané chování.

(tady jsem chtěl napsat příklad, ale byl - nevím proč - vyhodnocen jako spam a nějak jsem nezjistil, které slovo vadí :/)

Pěkně je důvod vzniku BDD popsán přímo na Wikipedii:
https://en.wikipedia.org/wiki/Behavior-driven_development#History

Pouzivam Behave na jednom projektu ale mam snim trosku problem a to ten ze nebezi paralelne, a nezdase ze by se to v dohledne dobe melo zmenit.

A ze vicemene vyzaduje python3 kvuli praci s unicodem ve vyjimkach.

Jeste jsem zapomel ze je taky velmi slozite delat combinatoricke testy, kdy chcete definovat sadu podminek chcete otestovat vsechny mozne kombinace. To se v jazyku Gherkin velmi spatne dela.