[Reverse]

Korzystacie w pracy z BDD (Cucumber, Gherkin) w testach które piszecie?

#testowanieoprogramowania

[Pmpa]

@Reverse: tak gowno totalne, kajdany na moich spracowanych rekach, w software housie fajna idea przez 1 miesiac wszyscy nietechniczni pokroju product ownera podjarani cos tam patrza, po tym okresie zostajesz z tym gownem do konca projektu bo i tak testy nikogo nie interesuja

[piolem]

@Reverse jak nie robi całą firma bdd a prawie nie ma takich firm to jest to przerost formy nad treścią.
Pisanie na siłę given when them jest mega nienaturalne i powoduje brak czytelności czyli zaprzeczenie idei bdd

[Reverse]

@Pmpa dzięki za odpowiedź. Pytam bo mam możliwość w pracy zastosować to wraz z Playwrightem podczas tworzenia nowego frameworka testowego i chciałem znać opinie innych osób, na reddicie sporo negatywnych komentarzow o gherkinje

[diarrhoea]

@Pmpa: 100% moje odczucia :<

[henk]

@Pmpa @piolem @Reverse @diarrhoea bo gherkin w takim ujęciu, że dostajesz stepy do zaimplementowania to faktycznie słabo. ale jak masz takiego robotframeworka, gdzie te bazowe stepy masz już gotowe, to takie BDD ułatwia pisanie testów kilka razy i automaty może klepać każdy manual.

[piolem]

@henk z doświadczenia wiem że każdy (prawie każdy) framework który jest keyword driven jest złym podejściem ..wliczajac w to robotframeworka.
Nie wchodząc w szczegóły ale z tych samych powodów co większość jak nie każdy framework, który automatyzuje przez recording... Może obecne AI i ML zmieni i te słabe rozwiązania nie będą tak słabe ale póki co to wygląda to dobrze u managerów którzy wciskają scime że można zatrudnić manula za 1/3

[Pmpa]

@henk: a to myslisz ze bez bdd nie masz tego podzielonego na reuzywalne funkcje?

[Pmpa]

@Reverse: skoro zadajesz takie pytanie w takim celu to framework bedzie sie nadawal do smietnika niezaleznie od bdd ( ͡° ͜ʖ ͡°)

[henk]

@Pmpa: tak sądziłem, myślałem, że bez BDD, to trzeba sobie pisać własny kompilator czy interpreter ;)

Tu nie chodzi o reużywalne funkcje, bo do podstawa. tylko każda budowa customowego frameworka na bazie jakiegoś innego to jest właśnie budowa tych reużywalnych funkcji - czyli tego co dostajesz w RF out of the box

@piolem - a jaka jest wada keyworda samego w sobie? przecież to taka sama funkcja jak każda inna: przyjmuje argumenty i zwraca wartość, nic ponad tym.
Nie mieszajmy w to recordingu, bo nie o

[Reverse]

@Pmpa: Pytam dlatego, że chce zaprojektować jak najlepszy framework który będzie dobrze służyl ;) Jak ma ktoś jakieś protipy to wszystko wskazane.

[diarrhoea]

@henk: Masz stepy, które trzeba i tak utrzymywać. Pisanie testów na zasadzie wywołania metody z parametrami to jest coś, co też umie zrobić każdy manual.

I przykład z driver.find_element(By.ID, "button-id").click() to jest najgorszy z możliwych tak naprawdę, coś takiego nigdy nie powinno się znaleźć w klasie testowej.

[Fristo]

@Reverse: Zdarzało mi się używać, chociaż wolałbym tego nie robić. Nie było u nas z tego żadnego pożytku.

[henk]

@diarrhoea no nie powinno się znaleźć i nie znajduje się, bo ktoś zbudował framework, z klasą pomocniczą, która ma metodę click_element, która jest w stanie przyjąć każdy typ lokatora. ukrył też zależność od driver. Czyli zrobił to co RF ma out of the box.

No chyba, że ktoś postąpił inaczej bardziej małpiaro: zbudował framework odtwarzając POM strony i najbal obiektów typu webelement, żeby sobie potem moc je wesoło importować i wywoływać

[diarrhoea]

@henk:
No ale co to za porównanie gherkina do driver.find_element(By.ID, "button-id").click().
Porównałbym do wyłącznie do czegoś w stylu wywołania metody o nazwie openCreateContract() czy co to tam by miało robić. A nie do tego, co ta metoda by miała mieć pod spodem.


I też wyznaję zasadę, że automatów nie powinien pisać ktoś, kto nie umie ich utrzymać.

[henk]

@diarrhoea: a ja jestem zdania, że każdy średnio rozgarnięta maupa jest w stanie utrzymać testy automatyczne. tylko większość przykładów jakie znajdują się w internecie i na jakich większość ludzi buduje potem swoje automaty wywodzi się od developerów, którzy najpierw zbudowali swój skomplikowany projekt, potem ktoś im kazał do tego zrobić testy, więc zrobili równie skomplikowane testy z milionem warstw abstrakcji i wszystkimi "wspaniałościami" programowania obiektowego.

nie będę też nikomu na

[diarrhoea]

a ja jestem zdania, że każdy średnio rozgarnięta maupa jest w stanie utrzymać testy automatyczne.

@henk: Też mi się tak wydawało, ale praca z różnymi ludźmi bardzo pokazała mi, że się mylę.

[Tang0]

@Reverse: jeśli chcesz zbudować najlepszy framework to od cucumberow trzymaj się z daleka, bo maintenance cost tego gunwa jest niekorzystny w relacji do tego co wnosi. A przyjmując sytuacje, że zespół deweloperski nie stosuje gherkina do ustalania AC czy trzymania dokumentacji to już w ogóle #!$%@? x100. To się jakoś tam spina jeśli absolutnie wszyscy są w tym wyuczeni i cały proces jest pod gherkina i na końcu ktoś rzeczywiście

[Pmpa]

@diarrhoea: xdd tlumaczenie nocodziarzowi/lowcodziarzowi podstaw to tak jakbys fizyke w podstawowce tlumaczyl na rownaniach rozniczkowych

[orkenzord]

@Reverse jak Playwright go obstawiam, że JS/TS.
Proponowałbym standardowy page object pattern (o ile ma to sens w aplikacji, którą testujesz). Dodatkowo zastosuj zasadę AAA (triple A), czyli Arrange/Act/Assert, żeby ładnie potworzyć "bloki" z akcjami w samych testach. Nie bój się dodawać komentarzy w kodzie - np. czasem warto opisać, że dane selectory dotyczą określonego modułu/widgeta/stepa w wizardzie lub co robi dana metoda. Jeśli chcesz dodać "bardziej ludzką" warstwę, to polecam

[orkenzord]

@Reverse a i #!$%@?ć BDD, nawet tego sobie nie rób błagam