Każdy Task jest automatycznie testowany, zanim będzie mógł zostać scalony — zarówno wąskimi testami jednostkowymi, jak i szerszymi testami end-to-end, które obciążają działającą aplikację. Widok Testing pokazuje testy projektu niezależnie od pojedynczego Task.

Testowanie

Testy w szczegółach Task

W widoku szczegółów Task krok Test pokazuje wynik testów jednostkowych projektu (ile przeszło, ile nie przeszło oraz wynik każdej awarii), a krok E2E pokazuje wynik scenariuszy end-to-end — symulowanych działań użytkownika w rzeczywiście działającej aplikacji. Jeśli Test lub E2E zakończy się niepowodzeniem, krok Fix otrzymuje szczegóły błędu, próbuje naprawić problem, po czym testy uruchamiane są ponownie; może się to automatycznie powtórzyć kilka razy. Jeśli testy nadal się nie powiodą po dozwolonej liczbie prób, Task otrzymuje status failed, a szczegóły błędu pozostają do niego dołączone.

Widok Testing i jego karty

Domyślnie widok Testing ma trzy wewnętrzne karty: History — Dashboard, History — Modules i Unit Tests. Dalsze karty — Setup, Dashboard, Verdicts, E2E Plans, Scenarios, Integration Tests, Release Tests i E2E Cockpit — istnieją, lecz są ukryte, dopóki nie zostaną włączone w dostosowaniu nawigacji.

Karta Unit Tests

Karta Unit Tests zawiera przycisk Run unit tests, sumy z ostatniego uruchomienia (passed, failed, skipped), tabelę Run History (data, passed, failed, total, czas trwania) oraz po prawej poszczególne testy wybranego uruchomienia z filtrami, takimi jak Passed i Failed. Kliknięcie uruchomienia w Run History wyświetla jego testy; filtr Failed pozwala przeczytać błąd każdego nieudanego testu. Uruchomienie, które się nie zakończyło, jest oznaczone jako crashed wraz z przyczyną i przyciskiem Ask AI to fix.

Werdykty Verify

Po testach krok Verify ponownie sprawdza każde kryterium akceptacji Task i zapisuje jeden z trzech werdyktów:

• passed — sprawdzenie zostało wykonane i zgadzało się z oczekiwaniami.
• failed — sprawdzenie zostało wykonane i nie zgadzało się; wynik podaje, co uruchomiono, czego oczekiwano i co zwrócono.
• unverifiable — sprawdzenia nie dało się w ogóle wykonać (na przykład wymaga działającej instancji, która nie jest dostępna). Nigdy nie powoduje to niepowodzenia Task; pozycja jest wymieniana jako oczekująca na ręczną weryfikację.

Build i Start/Stop

Można uruchomić build projektu, a następnie uruchomić lub zatrzymać jego działającą instancję na własnym, dedykowanym porcie — niezależnie od izolowanych instancji, które Pipeline uruchamia do testów E2E podczas Task.

Status na żywo i wyjście terminala

Na pierwszy rzut oka widać, czy instancja działa, jest budowana czy zatrzymana, a jej wyjście terminala/konsoli można śledzić na żywo — przydatne do potwierdzenia, że build się powiódł, lub do zdiagnozowania, dlaczego tak nie było.

Zatrzymywanie trwającego uruchomienia testów

Długo trwający zestaw testów jednostkowych można w każdej chwili zatrzymać bezpośrednio w widoku Testing, bez czekania na jego zakończenie. Jeśli serwer AITM zostanie zrestartowany w trakcie uruchomienia testów, uruchomienie zostaje bezpiecznie przerwane — po następnym starcie nie pozostanie w stanie „running"; serwer wykrywa to i czyści.

Wspólny budżet CPU/RAM dla testów

Testy jednostkowe i testy E2E współdzielą jeden ogólny budżet CPU i pamięci, który automatycznie dostosowuje się do rozmiaru serwera, na którym działa AITM. Testy są uruchamiane sekwencyjnie, aby ich łączne zużycie zasobów nigdy nie przeciążało hosta — chroni to przed awariami spowodowanymi jednoczesnym uruchamianiem wielu obciążeń testowych.

Historia werdyktów E2E

Każde uruchomienie testu end-to-end zarejestrowane dla tego projektu jest przechowywane na karcie Verdicts (domyślnie ukrytej), wraz z werdyktem (pass, feature bug, environment error itd.) oraz osią czasu, po której można przewijać wstecz, aby zobaczyć, jak zmieniała się kondycja testów w czasie.

Rozwijana lista wskaźnika błędów

Rozwijana lista wskaźnika błędów na górnym pasku pokazuje co najwyżej 10 ostatnich błędów, dzięki czemu pozostaje szybka i czytelna nawet w projektach z długą historią błędów. Zawsze zawiera odnośnik Open Bug Section — nawet gdy lista ostatnich pozycji jest pusta — więc lista nigdy nie kończy się ślepym zaułkiem; pełna lista błędów jest zawsze o jedno kliknięcie dalej, niezależnie od liczby ostatnich pozycji.