@ra_s: jak znasz cypressa to wybor jest prosty, ja cypressa uzywam do e2e/api i komponentow. Co do playwrighta to racja - na start malo przystepny

@Bulldogjob: oho strona nie działa a piątek 15 jest
Za to przetestowanie 1000PLN się należy

@wardx mockujesz bezpośrednio w testach po wait na alias requestu?

@wardx: dobra, odpaliłem sobie ten kod w głowie i już widzę, że to nie do końca zadziała, bo mówisz że tych requestów jest dużo więcej niż jeden i taki command wywołany raz nie zadziała, bo przecież nie będziesz tego klepał wszędzie po 100 razy.

Spróbuj może zrobić stub/mock w beforeEach() i podaj mu na chama każdy osobny endpoint jako osobny intercept, potem przerób to na coś co można sparametryzować, aPokaż całość

@imo0mfg:

pierwsza opcja: mockujesz api uzywajac msw https://mswjs.io/ czy pod playwrighta https://www.npmjs.com/package/playwright-msw po cypresa tez pewnie cos jest, najprostsza, najszybsza

opcja druga: no pewnie masz te rzeczy budowane do obrazow dockera, nie wiem jak to teraz wyglada w azure, wiec powiem na podstawie gitlaba czy tam bitbucketa bo dzialaPokaż całość

@imo0mfg: docker compose up backend docker compose up frontend, aktualizujesz repo z testami, docker compose run tests --env=local. Gdzie do locala masz przypisany localhost. Jak odpalasz na srodowisku testowym to --env=dev test staging czy jak tam macie??
Druga opcja to monorepo

cypress/inculded

@kaktusowyAloes: literówka. :)

@kaktusowyAloes: masz typo: included

@noisy: dzieki za podzielenie sie, odpale sobie jutro w pracy :)

@pasta_alla_carbonara a dlaczego chcesz zrobić zgodnie z definicją a nie zgodnie ze swoim doświadczeniem i wyróżnionymi dobrymi praktykami?

@pasta_alla_carbonara
Najlepiej napisać zgodnie z tym, jak się to tworzy w realnym życiu, uwzględniając estymacje, narzędzia, wymagania itd.

Np. test plan nie powinien zawierać przypadków testowych, a najwyżej informacje gdzie one będą spisywane.

@WolfSky jak potrzebujesz zgarnąć jakąś zmienna to czegoś wpisanego w cudzysłowie to najlepiej cudzysłów zamienić na ten znak pod ESC, wtedy przy pomocy tego dolara jak opisał to @Ecoo możesz zmienną wrzucić w miejsca gdzie używasz tego znaku pod ESC.

W największym skrócie, jeżeli kiedykolwiek będziesz chciał wrzucić co ze zmiennej jak masz to w ostatniej linijce to cudzysłów zastepujesz pod znakiem ESC, zmienna dajesz w klamrowe nawiasy, a przedPokaż całość

@bb-8: Ten od podrazy jest spoko

@Tyfus: Ten

@imo0mfg: POM nie jest wskazany dla cypressa (https://www.cypress.io/blog/2019/01/03/stop-using-page-objects-and-start-using-app-actions/) zasadniczo. Tu masz przykaldy: https://github.com/cypress-io/cypress-example-recipes/tree/master/examples/blogs__application-actions. Temat jest spory, bo do tego wchodzi jeszcze linter, polityka dot. trzymania zmiennych w aplikacji, rozdzielenie na smoke/pełną regresję.. Sporo też zależy co, jak i gdzie jest testowane w Twojej aplikacji. Ogolnie temat rzeka ;) Później coś podrzuce z linkow więcej, bo wydanie samo się nie zrobi

@pasta_alla_carbonara: jest jakieś inne opracowanie o app actions niż to od cypressa? nie znam nikogo kto by zrobił coś na app actions a wpis na ich blogu podświadomie mówi mi - robta tak jak mówimy inaczej źle używacie narzędzia

@AnonimoweMirkoWyznania: nie wiem czemu z anonimowych normalne pytanie to jest.

Ustawisz dobrze typecheck, eslint, prettier, lint-staged i husky i kod wygląda ładnie i tak samo u wszystkich

@AnonimoweMirkoWyznania AAA można dorzucić i jest gitówa, a tak serio to nie da rady tego tak o opisać generycznie. Dużo zależy od rodzaju oprogramowania też. Ciężko narzucić test suity z góry. Na bank polecam locatory/selectory oddzielić od warstwy testów a i nawet samej struktury POP. Chociaż nie zawsze to ma sens :).

@Misyl: Jesteś pewna, że chcesz do testowania API wykorzystać Cypressa? On generalnie służy do testów GUI tak naprawdę.

@Warrior: @Misyl: można robic requesty w API w cypressie jak najbardziej, ale najlepiej nie uzależniać testów cypressowych od działania API (badz niedziałania ;) ) i po prostu zamockować te requesty uzywając cy.intercept Co do testowania API, to postman jest spoko, ale spoko jest też pisanie testów API po prostu np w pythonie

@luxkms78: powodem jest to, że cypress jest trochę dużej na rynku niż playwright

@rcpkr7500: z udemy "zero to hero" jest dosyć polecany, sam go teraz robię.

@RaPtiLE: No póki co to jeszcze o wrażeniach za duo nie powiem bo robiłem go łącznie z 3.5h z czego 2h to się męczyłem z instalacją npma xd dziś i w tym tygodniu dopiero usiądę

@rcpkr7500 Ja nigdy o nim nie słyszałem, więc musiał się bardzo rzadko pojawiać w ofertach pracy

codeception

@rcpkr7500: ucz się języka, a nie frameworka najpierw. PHP w testach FE jest praktycznie nieużywane. Porównaj sobie aktywność/wsparcie na repo githuba tego codeception i na przykład cypressa, niebo a ziemia. Plus aktywnośc community, feature'y...

@astronic: performance testing, devopsowa strona testów - konfiguracja środowisk, bamboo/jenkins etc

@astronic: Ja bym na Twoim miejscu wziął coś wprost z Software Developmentu: Java, C#, Python etc.

@Bulldogjob siedzę w flaky testach od kiedy pamiętam i przyznam, że ten artykuł jest po prostu słaby. Miał on ogromny potencjał, który został zmarnowany. Można było wspomnieć coś coś o asynchronicznych akcjach i jak je obsługiwać. Dodatkowo coś więcej o guardach (które nawet sugerowane są w oficjalnej dokumentacji). Został pominięty wątek tzw. "pollerów" - gdzie używa się waity o krótkim interwale czasu. Brak informacji o tym jak można lokalnie zreprodukować flakyPokaż całość

@Bulldogjob: Polecam PlayWright.

@imo0mfg: ale przeciez użyłeś defacto ficture, w postaci describe'a, to jest dobre, normalne podejście, żeby testować sobie w pętli grupy danych :) Im mniej kodu cypressowego, tym lepiej. Jedyne czeego tam brakuje, to w pliku cypressowym nie ma teardowna po każdym teście.
Dorzuć to w formie afterEach() i będzie git.

@throaway: Dziennik aktywności
I potem masz kategorie i lecisz masowo, tylko chyba można kasować paczkami a nie wszystko naraz