Generator phpunit.xml

Generator pliku phpunit.xml

PHPUnit to najpopularniejszy framework testów jednostkowych w PHP. Plik phpunit.xml określa, które testy uruchomić i jak zbierać pokrycie kodu.

Najważniejsze sekcje

Przykład

Konfiguracja wskazuje katalog tests/Unit i mierzy pokrycie katalogu app. Uruchomienie: vendor/bin/phpunit lub php artisan test w Laravelu.

Pokrycie kodu

Do pomiaru pokrycia potrzebny jest Xdebug lub PCOV. Bez nich testy się uruchomią, ale raport pokrycia nie powstanie. Raport HTML wygenerujesz flagą --coverage-html.

Jak działa generator phpunit.xml

Generator pracuje w całości po stronie przeglądarki i nie opiera się na żadnej tablicy stałych ani zamkniętej liście dozwolonych elementów. To, co wpiszesz w formularzu, jest mapowane jeden do jednego na węzły i atrybuty dokumentu XML: nazwa zestawu staje się wartością atrybutu name, katalog trafia jako treść elementu directory, a ścieżka pojedynczego pliku jako element file. Nie ma tu ukrytych wartości domyślnych, które narzędzie dopisywałoby po swojej stronie.

Puste pola są pomijane w całości. Jeśli nie podasz katalogu pamięci podręcznej, odpowiedni element nie pojawi się w pliku, a PHPUnit zastosuje własne zachowanie domyślne. Dzięki temu wynik jest przewidywalny i wygodny w porównaniach: zmiana jednego pola zmienia dokładnie jedną linię konfiguracji, a reszta dokumentu zostaje bez zmian.

Drugi etap to serializacja drzewa do tekstu z zachowaniem kolejności wymaganej przez schemat, na który wskazuje atrybut xsi:noNamespaceSchemaLocation. PHPUnit waliduje plik przy starcie, więc kolejność sekcji i poprawność nazw atrybutów mają znaczenie — generator pilnuje obu tych rzeczy, ale nie zna wersji frameworka, którą uruchomisz, dlatego nie zagwarantuje, że każdy nowszy atrybut zostanie przyjęty przez starsze wydanie.

Narzędzie nie sięga do repozytorium: nie sprawdza, czy wskazany katalog istnieje, nie wykrywa zainstalowanych rozszerzeń ani nie odczytuje pliku composer.json. Dostajesz dokładnie taką deklarację, jaką wpiszesz, a weryfikacja należy do samego PHPUnit.

Przykład krok po kroku

1. Ustalasz punkt wejścia: jeden wpis bootstrap ze ścieżką vendor/autoload.php. Licznik węzłów struktury wynosi 1.
2. Dodajesz zestawy testów. Repozytorium ma katalog tests z trzema podkatalogami: Unit, Integration i Functional, więc wpisujesz trzy zestawy, każdy z własnym katalogiem. Licznik: 1 + 3 = 4.
3. Wskazujesz kod mierzony pod kątem pokrycia: dwa katalogi, src oraz app. Licznik: 4 + 2 = 6.
4. Ustawiasz zachowanie uruchomienia: cacheDirectory w katalogu .phpunit.cache, colors na true, executionOrder na depends,defects (dwie wartości) i stopOnFailure na false. To cztery atrybuty, więc łącznie masz 6 + 4 = 10 wpisów konfiguracji.
5. Pomijasz pola, których nie potrzebujesz: nie dodajesz żadnego wpisu do sekcji odpowiedzialnej za zmienne środowiskowe ani nie wykluczasz katalogów. Wynik to plik z 6 węzłami struktury i 4 atrybutami.
6. Kontrola deklaracji: gdybyś w kroku trzecim podał wyłącznie katalog src, pokrycie objęłoby jeden katalog z dwóch, czyli deklaracja dotyczyłaby połowy kodu źródłowego, a drugi katalog pozostałby poza raportem.

Elementy i atrybuty konfiguracji — tabela referencyjna

Praktyczne wskazówki

• Trzymaj plik w katalogu głównym projektu — PHPUnit szuka konfiguracji w katalogu, z którego go uruchamiasz, więc przenoszenie pliku do podkatalogu wymaga każdorazowego wskazywania go flagą configuration.
• Rozdziel zestawy według czasu wykonania — osobny zestaw dla szybkich testów jednostkowych i osobny dla wolniejszych pozwala uruchamiać ten pierwszy w trakcie pracy, a pełny przebieg zostawić na koniec.
• Nie wskazuj katalogu testów jako źródła pokrycia — jeśli dodasz katalog tests do listy mierzonego kodu, raport policzy również sam kod testów i zafałszuje odsetek.
• Wersjonuj wariant zapasowy, nie plik lokalny — plik z konfiguracją lokalną dopisz do ignorowanych, a do repozytorium wrzuć wariant wspólny dla zespołu, żeby każdy mógł nadpisać ustawienia bez konfliktów.
• Dodaj katalog pamięci podręcznej do ignorowanych — pliki stanu zmieniają się przy każdym przebiegu i zaśmiecają historię zmian.

Ograniczenia narzędzia

• Nie sprawdza ścieżek — generator nie wie, czy wskazany katalog ani plik istnieje. Literówka w nazwie katalogu objawi się dopiero przy uruchomieniu PHPUnit, czasem jako cicho pominięty zestaw testów.
• Nie zna twojego środowiska — nie ustali, czy masz zainstalowane rozszerzenie potrzebne do pomiaru pokrycia ani którą wersję frameworka uruchamiasz, więc nie dobierze pod to ustawień.
• Nie generuje plików towarzyszących — nie tworzy skryptu ładującego, nie instaluje zależności i nie zakłada katalogu na raporty. To wszystko musisz przygotować samodzielnie.
• Nie zastąpi konfiguracji środowiska — zmienne przekazywane z zewnątrz, nadpisywane w potoku ciągłej integracji albo w pliku lokalnym, mogą zmienić zachowanie przebiegu niezależnie od tego, co znajdzie się w wygenerowanym pliku.

Najczęstsze pytania