TESTLAB
Test E2E, kontrakt API i zestaw backendu kończą się raportem w jobie.
TestLab składa testy, które pipeline umie odpalić bez ręcznego przebiegu przed wydaniem. Runner, fixture i raport są artefaktami repo. Wynik czyta bramka jakości, zanim zmiana wejdzie do merge.
Trzy klasy testów, jeden pipeline
| Klasa | Runner | Co sprawdza job |
|---|---|---|
| Interfejs webowy | Playwright, Selenium | Scenariusz na środowisku testowym: selektor, stan, asercja. Zrzut i trace zostają artefaktem builda, gdy scenariusz padnie. |
| Kontrakt API | Test kontraktu przy schemacie endpointu | Metoda, ścieżka, status, kształt odpowiedzi. Zmiana schematu bez aktualizacji kontraktu czyni job czerwonym. |
| Backend | PHPUnit, Jest | Jednostka i integracja warstwy serwerowej na fixture, bez sięgania do danych produkcyjnych. |
Generator testów wchodzi od planu Team. Niższy plan Developer zostaje przy generatorze skryptów. Wyższy plan nie dokłada „więcej kliknięć w interfejsie”. Dokłada klasy testów i szablon joba, który te klasy uruchamia.
Fixture, środowisko, izolacja
Test czyta fixture z repo albo ze środowiska złożonego na czas joba. Dane w fixture są syntetyczne. PESEL, prawdziwy adres e-mail klienta albo zrzut tabeli produkcyjnej nie jest materiałem testowym. Jeśli scenariusz wymaga kształtu danych osobowych, kształt jest sztuczny, a umowa powierzenia poprzedza jakiekolwiek przekazanie danych realnych. Procedura jest opisana na stronie RODO.
Środowisko E2E ma własny URL, własne konto techniczne i własną bazę. Test nie loguje się na produkcję. Sekret konta testowego leży w magazynie CI. Selektor w teście wskazuje rolę albo atrybut testowy, nie klasę CSS wygenerowaną przez build, która zmieni się przy następnym deployu.
Job stawia środowisko, odpala zestaw, zbiera raport i gasi środowisko. Kolejny build nie dziedziczy rekordu zostawionego przez poprzedni, chyba że fixture jawnie mówi inaczej. Ta izolacja jest warunkiem tego, żeby czerwony test znaczył błąd zmiany, a nie resztkę cudzego przebiegu.
Raport, który bramka umie przeczytać
Runner wypisuje wynik w formacie, który system CI już zbiera: status przypadku, czas, komunikat asercji, ścieżka do trace przy porażce. Pipeline publikuje raport jako artefakt builda. Bramka przed merge czyta status zestawu. Brak raportu jest traktowany jak brak przejścia, nie jak „testów nie było, więc jest zielono”.
Test niestabilny nie zostaje w bramce w nieskończoność i nie jest po cichu wyłączany. Trafia do kwarantanny opisanej na stronie inżynierii jakości: osobny job, właściciel, termin naprawy albo usunięcia. Główna bramka zostaje przy zestawie, który jest powtarzalny.
Jak powstaje zestaw
-
01
Mapa ścieżek
Z repo i z opisu API wynika, które ścieżki są krytyczne: zapis, odczyt, błąd walidacji, uprawnienie. Nie powstaje test „całej aplikacji” bez tej mapy.
-
02
Szkic z generatora
Generator składa szkielet przypadku: arrange, act, assert, fixture. Szkielet przechodzi review jak kod produkcyjny.
-
03
Wpięcie w szablon joba
Job dostaje obraz z przeglądarką albo runtime backendu, katalog testów i zmienną środowiska. Komenda uruchomienia jest w repo.
-
04
Czerwony albo zielony build
Pierwszy przebieg na branchu ma prawo być czerwony. Poprawka idzie w kod albo w test. Merge czeka na zielony raport.
Granica względem reszty oferty
TestLab nie ustawia progów coverage i nie pisze strategii właścicielstwa katalogów. To jest inżynieria jakości. TestLab nie buduje adaptera do wewnętrznego systemu, którego nie da się pokryć gotowym runnerem. To jest zakres dedykowany. TestLab nie zastępuje testów, które zespół już ma: dokłada klasy, których w pipeline brakuje, i spina je z jobem, który już istnieje.
Runnerzy wymienieni na tej stronie (Playwright, Selenium, PHPUnit, Jest) są tymi, które inżynierowie KoneV przez lata wpiinali w pipeline zleceniodawców. Jeśli repo stoi na innym runnerze, szablon joba idzie pod ten runner, a nie pod zmianę całego zestawu narzędzi. Spółka dopiero startuje z własną ofertą. Praktyka runnerów jest praktyką osób i jest opisana na stronie o nas.