Sklep internetowy, w którym nie działa koszyk, przez kilka godzin nie zarabia ani złotówki – a właściciel często dowiaduje się o tym dopiero od klienta. Aktualizacja wtyczki, nowa wersja WooCommerce, zmiana motywu – każda z tych rzeczy może po cichu zepsuć ścieżkę zakupu. Dlatego przy sklepach, nad którymi pracuję, stawiam na automatyczne testy end-to-end w Cypressie. W tym wpisie pokazuję, co warto testować i jak podejść do tego bez budowania wielkiego projektu QA.
Czym są testy E2E i dlaczego akurat w sklepie?
Testy end-to-end (E2E) symulują prawdziwego użytkownika: otwierają przeglądarkę, klikają w przyciski, wypełniają formularze i sprawdzają, czy strona zachowuje się zgodnie z oczekiwaniami. W sklepie WooCommerce najważniejsza jest jedna rzecz – czy klient jest w stanie kupić produkt. Test E2E sprawdza dokładnie to, niezależnie od tego, która wtyczka czy fragment kodu odpowiada za poszczególne kroki.
Co testować w pierwszej kolejności
Nie trzeba od razu pokrywać testami całego sklepu. Zacznij od ścieżek, które bezpośrednio wpływają na sprzedaż:
- Strona główna i kategoria – czy się ładują i czy wyświetlają produkty.
- Dodanie produktu do koszyka – także produktu z wariantami, np. z wyborem rozmiaru.
- Koszyk – zmiana ilości, usunięcie produktu, poprawne przeliczenie sumy.
- Kod rabatowy – czy działa poprawny kod i czy błędny zwraca komunikat.
- Zamówienie – przejście przez checkout aż do strony z podziękowaniem.
- Formularz kontaktowy i logowanie – jeśli sklep z nich korzysta.
Przykładowy test: dodanie produktu do koszyka
describe('Cart', () => {
it('adds a product to the cart', () => {
cy.visit('/sklep/')
cy.get('[data-cy=product-card]').first().click()
cy.get('[data-cy=add-to-cart]').click()
cy.visit('/koszyk/')
cy.get('[data-cy=cart-item]').should('have.length', 1)
})
})Zwróć uwagę na atrybuty data-cy. Zamiast polegać na klasach CSS, które zmieniają się przy każdej aktualizacji motywu, dodaję do kluczowych elementów stabilne atrybuty przeznaczone wyłącznie do testów. Dzięki temu zmiana wyglądu nie psuje testów, a test psuje się tylko wtedy, gdy naprawdę zepsuje się funkcja.
Zasady, które oszczędzają nerwów
Testuj na kopii sklepu, nie na produkcji
Test, który składa zamówienie, tworzy prawdziwe zamówienie w bazie, wysyła maile i zmienia stany magazynowe. Dlatego testy uruchamiam na środowisku testowym (stagingu) z włączoną testową metodą płatności, np. płatnością przy odbiorze. Na produkcji wystarczą testy „tylko do odczytu”: czy strony się ładują i czy kluczowe elementy są widoczne.
Nie czekaj „na sztywno”
Komendy w stylu cy.wait(3000) spowalniają testy i i tak bywają zawodne. WooCommerce dodaje produkty do koszyka zapytaniami AJAX, więc lepiej przechwycić takie zapytanie przez cy.intercept() i poczekać dokładnie na jego zakończenie.
Każdy test niezależny
Test nie powinien zakładać, że poprzedni zostawił coś w koszyku. Każdy zaczyna od czystego stanu – dzięki temu wynik jest powtarzalny, a błąd łatwo zlokalizować.
Kiedy uruchamiać testy
- Po każdej aktualizacji WordPressa, WooCommerce, wtyczek lub motywu – najpierw na stagingu, potem dopiero na produkcji.
- Po zmianach w kodzie – najlepiej automatycznie, przy każdym pushu do repozytorium (np. przez GitHub Actions).
- Cyklicznie – prosty test „czy sklep żyje” uruchamiany codziennie potrafi wyłapać problem, zanim zauważy go klient.
Podsumowanie
Testy E2E w Cypressie nie są zarezerwowane dla dużych firm. Kilka dobrze dobranych scenariuszy – koszyk, kupon, zamówienie – daje właścicielowi sklepu spokój przy każdej aktualizacji, a deweloperowi pewność, że jego zmiana niczego nie zepsuła. Zacznij od jednego testu najważniejszej ścieżki zakupowej i rozbudowuj zestaw stopniowo.
