7 postów z tagiem "Playwright"

Magento 2 (obecnie Adobe Commerce) to potężna, modularna platforma e-commerce. Ze względu na swoją architekturę – zaawansowany backend oparty na strukturze EAV oraz dynamiczny frontend wykorzystujący biblioteki takie jak Knockout.js i jQuery – platforma ta stawia przed inżynierami jakości (QA) specyficzne i bardzo wymagające wyzwania.

Standardowe podejścia do testowania automatycznego często zawodzą w zderzeniu z Magento 2. Poniżej przedstawiamy szczegółową analizę największych wyzwań testowych specyficznych dla tej platformy oraz sprawdzone wzorce radzenia sobie z nimi.

Witamy w wielkim finale naszej serii! Przez ostatnie tygodnie budowaliśmy Piramidę Testów, walczyliśmy z asynchronicznością, przejmowaliśmy kontrolę nad bazą danych i API, pilnowaliśmy dostępności i bawiliśmy się w hakerów.

Jednak wszystkie te niesamowite testy, bez względu na to jak czysty jest ich kod, nie mają znaczenia, dopóki działają wyłącznie na komputerze dewelopera. Prawdziwa jakość rodzi się w Continuous Integration (CI/CD).

W tej części przyjrzymy się infrastrukturze i sposobom wpinania automatyzacji tak, by stanowiła twardą bramkę jakościową (Quality Gate).

Po ustabilizowaniu fundamentów strategii testowej i zapanowaniu nad środowiskiem (sieć oraz dane), czas spojrzeć na warstwę, z którą nasz użytkownik styka się bezpośrednio – interfejs.

W trzeciej części cyklu skupimy się na połączonych konceptach Testowania Wielopłaszczyznowego (Cross-X) oraz Testowania Wizualnego. Dlaczego warto o nich mówić razem? Ponieważ oba skupiają się na zagwarantowaniu, że niezależnie od urządzenia, silnika czy najmniejszej zmiany w CSS, nasza aplikacja wygląda i zachowuje się wzorowo.

W poprzedniej części cyklu o automatyzacji testów omówiliśmy fundamenty: Piramidę Testów i traktowanie testów jako pełnoprawnego kodu produkcyjnego (Page Object Model, TypeScript). Jednak nawet najlepiej napisany kod testowy będzie bezużyteczny, jeśli będzie działał na niestabilnym środowisku z nieprzewidywalnymi danymi.

Dlatego w tym bardzo "mięsistym" technicznie wpisie skupimy się na wyzwaniu, które spędza sen z powiek wielu testerom: Izolacja Danych i Zarządzanie Ruchem Sieciowym.

Zanim zaczniemy pisać o konkretnych narzędziach, konfigurować pipeline'y CI/CD i uruchamiać testy w środowiskach wirtualnych, musimy odpowiednio ustawić nasz "mindset". Budowanie stabilnego frameworka testowego zaczyna się od obranej strategii (Piramidy Testów), a kończy na uświadomieniu sobie kluczowej zasady: kod testów to kod produkcyjny.

W dzisiejszym świecie tworzenia oprogramowania (szczególnie aplikacji Fullstack), testowanie to nie tylko "dodatek", ale absolutny fundament utrzymania zdrowego cyklu życia projektu. W projekcie reads od początku postawiliśmy na wysoką jakość i zautomatyzowane procesy. Chciałbym podzielić się z Wami, dlaczego wybraliśmy Playwrighta do testów End-to-End (E2E), jak to narzędzie sprawdza się w praktyce oraz w jaki sposób wpięliśmy je w naszą "piramidę testów" na CI/CD.

W automatyzacji testów samo "passing green" to tylko połowa sukcesu. Prawdziwym wyzwaniem jest visibility i redukcja czasu potrzebnego na debugowanie. W moim projekcie reads wdrożyłem zaawansowany system raportowania, który zamienia surowe logi w czytelną mapę drogową jakości. Zamiast analizować konsolę, dostajemy pełny wgląd w stan aplikacji w czasie rzeczywistym po każdym wdrożeniu.