12 postów z tagiem "Testing"

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 zbudowaniu Piramidy Testów, opanowaniu mockowania i wdrożeniu testów wizualnych, mogłoby się wydawać, że nasza praca jest skończona. Niestety, testowanie tzw. "szczęśliwych ścieżek" (Happy Paths) to zaledwie wierzchołek góry lodowej.

W czwartej części naszego cyklu poruszymy obszary najczęściej ignorowane w procesie deweloperskim, aż do momentu krytycznego błędu na produkcji. Skupimy się na Dostępności (A11y), Bezpieczeństwie (Security) oraz nieliniowym, hakerskim podejściu do własnej aplikacji, czyli Testowaniu Adwersaryjnym.

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.

Jako inżynier bezpieczeństwa, który zaczynał od analizy pakietów w Wiresharku i ręcznego „fuzzowania” formularzy, z pewnym sentymentem wspominam rok 2005. Wtedy bezpieczeństwo aplikacji webowych opierało się na naiwnym zaufaniu do protokołów GET i POST. Parametry w URL-u były dosłownie zaproszeniem do przejęcia bazy danych (SQLi), a brak walidacji po stronie serwera był normą, nie wyjątkiem. Królowała era monolitycznych systemów, w których jedna luka w kodzie oznaczała natychmiastowe RCE (Remote Code Execution). Zamiast podejścia Secure by Design, żyliśmy w świecie „perymetrycznej obrony”, wierząc, że firewall ochroni nas przed wszystkim.

Mam VPS z kilkoma usługami dockerowymi: WireGuard, Pi-hole, n8n, SonarQube, środowisko staging dla mojego projektu. Przez długi czas jedynym "monitoringiem" było SSH i docker ps. Postanowiłem to zmienić.

Ten wpis to kopalnia wiedzy z mojego wdrożenia — dowiesz się z niego, jak poprawnie skonfigurować cały stack i jak poradzić sobie z wyzwaniami, które mogą pojawić się w nowoczesnych środowiskach Docker (jak Ubuntu 24.04). To nie jest zwykły tutorial "kopiuj-wklej", ale praktyczny przewodnik po tym, jak sprawić, by monitoring na VPS naprawdę działał.

Jako programiści często wpadamy w pułapkę dokładania kolejnych narzędzi i skanerów do naszych pipeline'ów w CI/CD, nie zważając na to, jak mocno wydłuża to czas trwania całego procesu. Chcemy mieć zrobiony linting, przetestowany kod (zarówno jednostkowo, jak i E2E), jakość potwierdzoną przez SonarQube i wreszcie bezpieczeństwo obrazów Dockerowych za pomocą Trivy.