W przypadku gotowych skryptów stron internetowych często pojawia się podobny scenariusz: klient kupuje działający system, a następnie chce go dostosować do swoich potrzeb.

Dodanie nowego modułu, zmiana sposobu działania formularza, integracja z zewnętrznym systemem, dodatkowe pola, nowe uprawnienia użytkowników — takie modyfikacje są naturalnym etapem rozwoju aplikacji.

Problem pojawia się wtedy, gdy po wielu zmianach nikt nie sprawdza, czy wcześniejsze funkcje nadal działają poprawnie.

W małych projektach często słyszę:

„Przecież wystarczy sprawdzić ręcznie, czy działa”.

Na początku może to być prawda. Jednak im większa aplikacja, tym więcej zależności pomiędzy funkcjami. Zmiana jednej części systemu może przypadkiem uszkodzić inną, pozornie niezwiązaną funkcję.

Właśnie dlatego stosuje się testy automatyczne.

Czym są testy automatyczne?

Testy automatyczne to dodatkowy kod, którego zadaniem jest sprawdzanie, czy aplikacja działa zgodnie z założeniami.

Zamiast za każdym razem ręcznie:

• logować się do panelu,
• tworzyć użytkownika,
• dodawać wpis / ogłoszenie / post,
• wysyłać formularz,
• sprawdzać wiadomości e-mail,
• testować uprawnienia,

możemy przygotować scenariusze, które komputer wykona za nas w kilka – kilkadziesiąt sekund.

Dzięki temu po większej aktualizacji możemy szybko sprawdzić, czy najważniejsze elementy systemu nadal działają.

Rodzaje testów stosowanych w aplikacjach PHP

1. Testy jednostkowe (Unit Tests)

Testy jednostkowe sprawdzają najmniejsze elementy aplikacji — pojedyncze klasy, metody lub funkcje.

Przykład:

W Notice3 mamy funkcję odpowiedzialną za obliczenie ceny wystawienia ogłoszenia.

Możemy sprawdzić:

• czy darmowe ogłoszenie faktycznie kosztuje 0 zł,
• czy płatna opcja nalicza poprawną kwotę,
• czy cena zależy od wybranej kategorii

Test jednostkowy nie sprawdza całej strony. Sprawdza konkretną część logiki.

Zaletą jest szybkość — takich testów można mieć setki i uruchamiają się bardzo szybko.

2. Testy integracyjne (Integration Tests)

Testy integracyjne sprawdzają, czy różne elementy aplikacji współpracują ze sobą.

Przykład:

Użytkownik dodaje ogłoszenie:

1. wypełnia formularz,
2. dane trafiają do bazy danych,
3. wysyłane jest powiadomienie e-mail,
4. ogłoszenie pojawia się na stronie.

Każdy element osobno może działać poprawnie, ale problem może pojawić się podczas ich współpracy.

Test integracyjny sprawdza właśnie taki kompletny przepływ.

3. Testy funkcjonalne (Functional Tests)

Testy funkcjonalne sprawdzają aplikację z perspektywy użytkownika.

Można je porównać do tego, co robi człowiek korzystający ze strony.

Przykład:

• wejście na stronę logowania,
• wpisanie danych,
• kliknięcie przycisku,
• sprawdzenie, czy użytkownik został zalogowany.

W Symfony często wykorzystuje się do tego narzędzia dostępne w samym frameworku, które pozwalają symulować zachowanie użytkownika.

Smoke testy — szybkie sprawdzenie, czy wszystko działa

Smoke testy (testy dymne) to podstawowy zestaw najważniejszych sprawdzeń wykonywany po wdrożeniu zmian.

Nazwa pochodzi ze świata elektroniki.

Jeżeli po włączeniu nowego urządzenia nie pojawia się dym, można przejść do dalszych testów. 🙂

W przypadku aplikacji chodzi o szybkie sprawdzenie:

• czy strona się otwiera,
• czy można się zalogować,
• czy panel administracyjny działa,
• czy baza danych odpowiada,
• czy najważniejsze formularze działają.

Smoke test nie sprawdzi wszystkiego, ale szybko wykryje poważne błędy.

Regresja — czyli czy nie zepsuliśmy czegoś, co wcześniej działało?

Jednym z największych problemów przy rozwijaniu istniejących systemów jest regresja.

Regresja oznacza sytuację, w której nowa zmiana powoduje problem w starej funkcji.

Przykład:

Klient chce dodać nowe pole w formularzu ogłoszenia.

Zmiana zostaje wykonana i nowe pole działa.

Kilka dni później okazuje się, że:

• wyszukiwarka nie znajduje części wpisów,
• administrator nie może edytować ogłoszeń.

Dlaczego?

Bo nowa funkcja wpłynęła na inne elementy systemu.

Testy regresji pomagają wykryć takie sytuacje wcześniej.

Dlaczego warto pisać testy przy rozwoju skryptu Notice3?

Notice3 jest aplikacją opartą na Symfony, czyli frameworku przeznaczonym do budowania rozbudowanych i długoterminowo rozwijanych systemów.

W takich projektach kod często rozwija się latami:

• dochodzą nowe funkcje,
• zmieniają się wymagania klientów,
• pojawiają się integracje,
• zmieniają się wersje PHP i bibliotek.

Bez testów każda większa zmiana zwiększa ryzyko.

Można oczywiście ręcznie sprawdzić kilka najważniejszych miejsc, ale człowiek:

• może coś pominąć,
• nie pamięta wszystkich zależności,
• nie wykona za każdym razem identycznego scenariusza.

Automatyczne testy wykonują dokładnie te same sprawdzenia za każdym razem.

Czy każda aplikacja potrzebuje tysięcy testów?

Nie zawsze.

W praktyce najlepsze podejście to testowanie najważniejszych elementów.

Dla systemu typu Notice3 warto zacząć od:

• logowania użytkowników,
• rejestracji,
• dodawania i edycji ogłoszeń,
• płatności,
• wysyłki wiadomości e-mail,
• uprawnień administratorów i moderatorów,
• najważniejszych integracji.

Nie chodzi o to, aby testować każdą linijkę kodu.

Chodzi o zabezpieczenie miejsc, których awaria powoduje największe problemy.

Testy jako inwestycja, a nie dodatkowy koszt

Często testy są traktowane jako niepotrzebny wydatek.

W rzeczywistości ich zadaniem jest ograniczenie kosztów w przyszłości.

Jedna godzina poświęcona na napisanie testu może zaoszczędzić wiele godzin szukania błędu po wdrożeniu zmian.

Szczególnie w przypadku systemów, które są rozwijane przez wiele lat, testy stają się dokumentacją działania aplikacji.

Kod mówi programiście, jak coś zostało napisane.

Test mówi, jak dana funkcja powinna działać.

Podsumowanie

Jeżeli aplikacja jest ciągle rozwijana, testy automatyczne przestają być luksusem, a stają się narzędziem zapewniającym bezpieczeństwo zmian.

W przypadku skryptów takich jak Notice3, gdzie wielu klientów wykonuje własne modyfikacje i rozbudowuje system pod swoje potrzeby, odpowiedni zestaw testów pozwala szybciej wykrywać problemy i bezpieczniej rozwijać aplikację.

Najlepszy moment na rozpoczęcie testowania jest wtedy, gdy projekt jest jeszcze stosunkowo łatwy do objęcia kontrolą — zanim liczba zmian i zależności znacząco wzrośnie.