Testy z telefonu, wraz z kryteriami pokrycia
Sześć poziomów testów, kryteria pokrycia od instrukcji do MC/DC i dlaczego mieć wyniki w telefonie jest zaletą.
Zakładka Projekt → Testy to nie tylko lista tego, co pada. To miejsce, w którym zlecasz testy, czytasz ich historię i przeklikujesz się od padającego przypadku do tego, co on właściwie sprawdza — a wszystko z telefonu, bez jednej linijki promptu.
Poziomy
Testy są podzielone na sześć poziomów: jednostkowe, integracyjne, systemowe, E2E, wydajność UI i wydajność backendu. Przełączają się u góry i każdy trzyma własną historię Przebiegów.
Ten podział nie jest kosmetyczny. Padający test jednostkowy znaczy coś innego niż padający E2E — a kiedy widzisz jedno i drugie na jednej liście, tracisz właśnie tę informację, dla której poziomy istnieją.
Kryteria pokrycia — i po co w ogóle
Kiedy zlecisz testy zdaniem „napisz testy”, dostaniesz testy. Pytanie, co sprawdzają — a na to nikt nie ma odpowiedzi, dopóki coś nie padnie na produkcji.
Kryterium pokrycia to reguła mówiąca, kiedy testów jest dość. To nie procent; to zdanie, które da się sprawdzić:
- Pokrycie instrukcji
- Każda instrukcja wykona się przynajmniej raz. Najtaniej i najsłabiej — kod się uruchomił, ale o jego gałęziach to nie mówi nic.
- Pokrycie gałęzi
- Każdy warunek wyjdzie raz prawdziwie i raz nieprawdziwie. Tu testy zaczynają znajdować błędy.
- MC/DC
- Przy każdym warunku składowym pokazuje się, że sam zmienia wynik. Drogie, ale przy warunkach złożonych to jedyny sposób, żeby się dowiedzieć, że jeden z nich jest zbędny.
- Pair-wise
- Każda para wartości z różnych charakterystyk spotka się w co najmniej jednym teście. Ułamek kombinacji, większość błędów.
W aplikacji wybierasz kryterium przy zlecaniu testów i widzisz przy nim, jak jest wymagające — zanim Agent zacznie pracować. To ta różnica wobec „napisz testy”: wiesz, co dostaniesz, a Agent wie, kiedy przestać.
Przegląd kryteriów dla twojego projektu niech zestawi Agent. Dopisze przy nich, jak wymagające są właśnie tutaj — inne są przy parserze, inne przy formularzu.
Dlaczego mieć to w telefonie jest zaletą
- Wyniki czyta się i bez połączenia. Przebiegi są pobrane, więc grzebiesz w nich choćby w samolocie.
- Od padającego przypadku prowadzi przejście do jego opisu w dokumentacji i do zrzutu ekranu z chwili upadku. Nie do stu linijek logu.
- Historia w poprzek Przebiegów pokaże niestabilny test — ten, który raz przechodzi, a drugi raz nie. W terminalu go pamiętasz, tu go widać.
- Zmierzone wartości w testach wydajności mają przebieg w poprzek Przebiegów. Jedna liczba o pomiarze nie mówi nic, kierunek tak.
- Zlecenie kolejnych testów to kilka stuknięć, nie pisanie promptu. Wybiera się poziom i kryterium, reszta należy do Agenta.
Skąd biorą się wyniki
Aplikacja czyta JUnit XML, czyli format, który umie wypluć niemal każde narzędzie testowe. Agent zapisuje go do projektu, a telefon pobiera go z lustrem — żadnej usługi pomiędzy, żadnego wysyłania gdziekolwiek.
Kształt, w jakim zapisywane są wyniki, ustala skill aplikacyjny. Skille wkłada się do projektu z zakładki Projekt, sekcja Skille aplikacyjne; bez nich zobaczysz tylko to, co w projekcie już jest.
Zacięło się gdzie indziej niż to, co tu jest? Napisz na support@coden-app.com.