Wszystkiego dobrego w Nowym Roku! Bardzo Ci dziękujemy za przejrzenie całego materiału. :) Istotnie poruszyliśmy sporo tematów, mniej lub bardziej związanych ze skalowaniem, natomiast staraliśmy się aby za bardzo nie odbiegać od myśli przewodniej - czyli właśnie skalowania projektów programistycznych. Mamy nadzieję, że wyszło dobrze i każdy znalazł w materiale coś dla siebie. Nie byliśmy w stanie w powyższym materiale skupić się na wszystkim, o niektórych wspomnieliśmy tylko w kilku słowach. Sumarycznie zrobiliśmy ok 5h nagrania, ale musieliśmy jakoś skompresować ten materiał. Mamy sporo pomysłów na kolejne odcinki, również na tematy, o których wspominasz. Widzimy, że jest zainteresowanie, więc prawdopodobnie omówimy też pozostałe tematy. Wypadałoby jeszcze poruszyć kwestię zarządzania Backlogiem Produktu (też na poziomie PRB - Problem Report Board), Git flow (Merge/Pull Requests oraz Code Review), jak w tym wszystkim znajduje się PMO (Project Management Office), jak używać Scruma w połączeniu z elementami V-Cycle, jaką rolę spełnia QA, itd... Wciąż jesteśmy ciekawi jak materiał zostanie odebrany. Trochę odbiega od obecnej mody - nie przedstawiamy najnowszych frameworków, nie skupiamy się na uzwninnianiu już zwinnych metod projektowych, zamiast tego koncentrujemy się na rzemiośle, proponujemy odświeżyć, już nieco zapomniane techniki i dopasować je do obecnych czasów.

Ekstra :D

Jeżeli o scrollowanie to do głowy przychodzi mi wykorzystanie 'mouse.wheel(deltaX, deltaY)' albo 'locator.scrollIntoViewIfNeeded(options)'. Czy któreś z nich zadziała w Twoim przypadku?

const successMessage = await page.locator('#success_message.alert-success'); await expect(successMessage).toContainText('Your order has been placed successfully!'); przy użyciu selektora też pokazuje błąd :(

@@adamcegielka Czy ta wiadomość jest dostępna tylko w przypadku udanej transakcji? Czy await expect(successMessage).toBeVisible(); zadziała? W ten sposób sprawdzimy, czy jesteśmy w stanie w ogóle złapać to powiadomienie w przeglądarce. Jeżeli powiadomienie ma różne klasy w zależności od statusu transakcji, to może jesteśmy w stanie wykorzystać atrybuty Locatora i użyć toHaveAttribute() albo to HaveClass(). Jak myślisz?

Przyjemność po mojej stronie. Dobrze wiedzieć, że takie rzeczy też się przydają. :D

Dzięki! Dodane chaptery :)

Słuszna uwaga. Zgadzam się, że wtedy klasa będzie bardziej przejrzysta :)

Przemyślałem kwestię utrzymywania projektu, ale chyba coś mi umyka. Jeżeli dobrze rozumiem twoje rozwiązanie, to definicję lokatorów przenieślibyśmy do samych testów. Ideą Page Object Model jest trzymanie wszystkiego w 1 miejscu na wypadek czestych zmian samych Selectorów. Czy o to Ci chodziło?

@@zwinnapanda ps. zamykanie jednej czynności typu click() w odrębnej metodzie w klasie moim zdaniem jest kiepskie ten gość z tego repozytorium to robi ale dla mnie nie widzę w tym żadnego sensu sporo osób tak robi ale jeszcze żaden nie odpowiedział mi na pytanie dlaczego

@@mariuszpodgorski6695 Wszystkie selectory wydzieliłem do osobnej klasy, żeby trzymać je w jednym miejscu na wypadek późniejszych zmian. Dzięki temu jeżeli kiedyś będę potrzebował coś zmienić to robię to w jednym miejscu, a nie w samych plikach z testami. Dodatkowo każda klasa trzyma selektory tylko dla konkretnej strony. Dla mnie takie rozwiązanie jest czytelne. Nie wiem czy dobrze Cie rozumiem. Czy mógłbyś pociągnąć temat i może podrzucić fragment jakiegoś kodu? :)

@@mariuszpodgorski6695 Page Object Model to wzorzec pisania testów automatycznych. www.browserstack.com/guide/page-object-model-with-playwright

Hey. Can you send send me some details via email from "information" tab? What would be the scope, audience etc?

I could not find your email....please drop your email address here... I will send you details

@@maoskitchen Hit me at zwinnapanda [at] gmail [dot] com

Check your email please

Jeżeli ciągniesz jakiś przedmiot (na przykład za przywiązaną do niego linę) to widzisz co masz przed sobą. Wiesz ile masz jeszcze miejsca i jak nie spowodować zatoru. Kiedy zaczynasz pchać duży przedmiot to przed sobą masz tylko ten obiekt (w naszym przypadku zadanie). Skupiasz się tylko na nim i tym, żeby iść przed siebie. W kontekście procesowania zadań na tablicy kanbanowej chodzi o patrzenie na nią z prawej strony do lewej i zajmowanie się pierwszym zadaniem, z którym można coś zrobić. Najpierw sprawdzamy co można przetestować, potem gdzie zrobić code review, a następnie co developować. Dzięki temu wszystkie zadania są sprawnie procesowane i tablica jest zawsze aktualna. Jeżeli będziemy patrzeć od lewej do prawej to zawsze wszyscy będą sie skupiać najpierw na developowaniu, potem na code review i następnie na testowaniu. Może to doprowadzić do sytuacji, że gdzieś w naszym systemie będzie pojawiał się zator i zeby się go pozbyć trzeba będzie procesować większe ilości zadań w tym samym momencie.