Zyski:
- Możliwość tworzenia testów jednostkowych, przypadków brzegowych i analizy luk pokrycia za pomocą sztucznej inteligencji
- Możliwość wydrukowania oczekiwań testowych w oparciu o specyfikację, a nie aktualne zachowanie kodu
- Możliwość sprawdzenia, czy test rzeczywiście chroni, poprzez wstrzykiwanie błędów
Pisanie testów to jedno z najbardziej wartościowych zadań, które większość programistów odkłada na później. Dobry zestaw testów jest dowodem na to, że kod działa zgodnie z oczekiwaniami i ratunkiem dla przyszłych zmian. Problem polega na tym, że pisanie testów jest powtarzalne i czasochłonne — dokładnie w tym rodzaju pracy, w której sprawdza się sztuczna inteligencja. Jest jednak pewien haczyk: sztuczna inteligencja często testuje istniejące zachowanie kodu, a nie to, jakie powinno być. Zarządzanie tą różnicą jest istotą tej jednostki.
W tej części nauczysz się testowania jednostkowego (testowania, które testuje samą funkcję, w izolacji), testów przypadków brzegowych i generowania danych testowych za pomocą sztucznej inteligencji; zamknięcie luk w zasięgu testów; i dlaczego ślepe ufanie testom AI jest niebezpieczne.
Dwie strony testowania: naprawianie zachowania a weryfikacja
Test może służyć dwóm różnym celom. Pierwsza to weryfikacja: sprawdza, czy kod jest poprawny, czy jest zgodny ze specyfikacją. Drugie to ochrona przed regresją: zamraża zachowanie kodu dzisiaj, więc jeśli ktoś jutro przypadkowo go zmieni, test się zepsuje i powiadomi.
AI jest bardzo dobra w tym drugim; Sprawdza kod i generuje przypadki, które testują „co obecnie robi”. Jeśli jednak kod od początku będzie błędny, sztuczna inteligencja może przypisać niewłaściwe zachowanie jako „poprawne”. Musisz więc przejrzeć potwierdzenie każdego testu generowanego przez sztuczną inteligencję: „Kod zwraca 42, a test oczekuje 42” nie oznacza, że 42 jest poprawną odpowiedzią.
Uwaga: Jeśli sztuczna inteligencja przejdzie test, nie oznacza to, że kod „działa”; oznacza to po prostu „zachowuje się zgodnie z oczekiwaniami AI”. Ty decydujesz, czy oczekiwania są prawidłowe, czy nie, patrząc na specyfikację.
Krok po kroku: pisanie solidnych testów z wykorzystaniem sztucznej inteligencji
- Podaj specyfikację, a nie tylko kod. Jeśli dodasz informację „Ta funkcja powinna to zrobić”, sztuczna inteligencja może zapisać prawidłowe oczekiwanie; Przetestuje bieżące zachowanie, jeśli po prostu podasz kod.
- Zapytaj o obudowy Edge. Puste, null, zero, ujemne, za duże, zły format, współbieżność — wyraźnie usuń szczęśliwą ścieżkę.
- Określ strukturę i styl testowania. „użyj pytest”, „wzorzec Arrange-Act-Assert”, „pozwól każdemu testowi przetestować jedną rzecz” itp.
- Sprawdź oczekiwania (twierdzenie). Porównaj ze specyfikacją, że każde potwierdzenie sprawdza poprawną wartość.
- Zamknij luki w zakresie. Podaj istniejące testy i zapytaj „które gałęzie i przypadki nie zostały przetestowane?” sprawić, że zapytasz; następnie sprawdź wykonane dodatkowe testy.
Trzy mini etui
Przypadek 1 — Pokrycie od 52% do 85%. Pokrycie testowe jednego modułu serwisowego wyniosło 52%. Zespół przekazał AI istniejące testy, zlecił jej utworzenie listy nieprzetestowanych gałęzi i wygenerowanie dla nich testów. Dzięki przeglądowi ręcznemu zasięg wzrósł do 85%; W trakcie tego procesu sztuczna inteligencja odkryła rzeczywisty błąd (ścieżkę, która zwróciła błędny kod błędu) w gałęzi błędu, która nigdy wcześniej nie była testowana.
Przypadek 2 — Pułapka fałszywego fiksacji oczekiwań. Funkcja zaokrąglania pieniędzy była w rzeczywistości błędna; Zamiast zaokrąglić 2,675 do 2,67, zaokrąglono 2,67 zamiast 2,68. Sztuczna inteligencja spojrzała na kod i napisała „assert round_money(2.675) == 2.67” – zamrażając błąd jako „true”. Kiedy programista przeczytał specyfikację, poprawił oczekiwania i wyłapał prawdziwy błąd. Testowanie reguły, a nie kodu, zrobiło różnicę.
Przypadek 3 — Eksplozja stanu krawędziowego. Prosząc sztuczną inteligencję tylko o „przypadki skrajne” dla funkcji zakresu dat; Uzyskano 8 przypadków, takich jak początek=koniec, interwał odwrotny, rok przestępny 29 lutego, różne strefy czasowe i interwał zerowy. Dwa z nich (odwrotne odstępy i rok przestępny) faktycznie powodowały błąd. Często pomija się ręczne rozpatrywanie tych przypadków; Sztuczna inteligencja stała się tutaj partnerem „burzy mózgów w kluczowych przypadkach”.
Cztery szablony do kopiowania
Generowanie testów w oparciu o specyfikację:
Rola: Programista piszący testy. Framework: {{pytest/JUnit/Jest...}}.Co funkcja POWINNA ZROBIĆ (specyfikacja): {{rule}}Napisz testy dla poniższej funkcji. Zapisz oczekiwania zgodnie ze specyfikacją, a NIE bieżący wynik kodu. Szczęśliwa ścieżka + dodaj co najmniej 4 przypadki Edge. Niech każdy test sprawdza jedną rzecz, użyj nazwy opisowej. {{funkcja}}
Burza mózgów w sprawie Edge:
Wymień przypadki brzegowe/awarie, które należy wypróbować podczas testowania tej funkcji (null, null, punkty przerwania, zły format, współbieżność, błąd zewnętrzny). Dla każdego przypadku: dane wejściowe, oczekiwane zachowanie. NIE pisz jeszcze kodu, po prostu wypisz.{{funkcja}}
Analiza luk w pokryciu:
Poniżej funkcje i dostępne testy. Które gałęzie, warunki i przypadki nie zostały przetestowane? Wypisz braki i napisz nowe testy tylko dla braków. Nie powtarzaj już istniejących. Funkcja:{{funkcja}}Testy:{{existing_tests}}
Dane testowe / generowanie próbnych obiektów:
Generuj realistyczne dane testowe dla testów {{function/service}}: osobno ważne próbki, próbki graniczne i próbki nieważne. Zaproponuj proste, próbne zachowanie zależności zewnętrznej {{X}}. Wykorzystywanie prawdziwie poufnych danych/PII; Generuj fałszywe dane.
Słaba zachęta/silna zachęta
Słabe: „Napisz test dla tej funkcji”.
Mocne: "z pytestem. Funkcja Apply_discount(total, percent) — reguła: rabat musi wynosić 0%–30%, poza zakresem powinien zostać wyrzucony ValueError, wynik powinien zostać zaokrąglony do 2 miejsc po przecinku. Zapisz oczekiwania według tej RULE (nie według kodu). Szczęśliwa ścieżka + te skrajne przypadki: 0%, 30%, 31% (błąd), ujemne, suma=0. [kod]"
Podaje silną zasadę wydania i mówi: „pisz oczekiwania zgodnie z regułą, a nie kodem”; To jedno zdanie zamyka pułapkę polegającą na naprawianiu niewłaściwego zachowania przez sztuczną inteligencję.
Typ testu
Wkład AI
kontrola ludzka
Udanych testów jednostki drogowej
szybki szkielet
Czy oczekiwanie jest słuszne?
Obudowy Edge
Obszerna burza mózgów
Wyeliminuj to, co nieistotne
Wypełnianie luk w zakresie
Znajduje pominięte gałęzie
Potwierdź znaczenie
Dane testowe/makieta
Tworzy realistyczną próbkę
Brak PII, kontrola realizmu
Testy zarządzają jakością, a nie ją gwarantują
Wysokie pokrycie testu daje pewność, ale może też wprowadzać w błąd: 100-procentowe pokrycie oznacza, że „każda linia została wykonana”, a nie „każda linia jest poprawna”. Zwiększenie zasięgu dzięki sztucznej inteligencji jest łatwe; Prawdziwą wartością jest spisanie znaczących oczekiwań. Wartością testu jest jego zdolność do złamania kodu i ostrzeżenia o jego złamaniu. Dlatego testy generowane przez sztuczną inteligencję opierają się na pytaniu „czy kod naprawdę psuje się pod wpływem zmian?” Przetestuj to za pomocą pytania; Celowe złamanie linii i zobaczenie przerwy w teście (pomysł mutacji) jest dowodem na to, że test zadziałał.
Wskazówka: Aby sprawdzić, czy test napisany przez sztuczną inteligencję działa, utwórz mały błąd w kodzie (np. zmień + na -) i sprawdź, czy test się nie powiedzie. Jeśli się nie zepsuje, ten test cię nie ochroni.
Typowe błędy
- Prośba o test bez podawania reguły. Model zamraża bieżące zachowanie; naprawia błąd jako „true”.
- Akceptowanie oczekiwań bez ich czytania. Testowanie wprowadza w błąd, jeśli nie sprawdzisz, czy asercje sprawdzają poprawną wartość.
- Właśnie testuję szczęśliwą ścieżkę. Prawdziwe błędy żyją na marginesie; Zapytaj wyraźnie o przypadki Edge.
- Mylenie zakresu z celem. Wysoki odsetek nie gwarantuje prawidłowego zachowania.
- Tworzenie prawdziwych/ukrytych danych jako danych testowych. Dane ani tajemnice klientów nie powinny być wprowadzane do testów i przechowywania; Generuj dane syntetyczne.
Podsumowując
Sztuczna inteligencja eliminuje większość powtarzalnych obowiązków związanych z pisaniem testów: tworzy szybkie szkielety, duże listy przypadków brzegowych i analizy luk pokrycia. Ale najważniejszym punktem są oczekiwania: sztuczna inteligencja ma tendencję do testowania bieżącego zachowania kodu, podczas gdy testy powinny być pisane zgodnie ze specyfikacją. Podaj regułę, sprawdź oczekiwania, egzekwuj przypadki Edge i sprawdź, czy testy rzeczywiście chronią, wprowadzając błąd. Pokrycie testami jest narzędziem, a nie celem.
Zadanie aplikacji
Wybierz funkcję i najpierw wydrukuj test AI, po prostu podając jej kod; Zwróć uwagę na oczekiwania. Następnie wydrukuj test ponownie, podając specyfikację (wymagane zachowanie) dla tej samej funkcji. Porównaj oczekiwania dwóch zestawów testowych: czy są jakieś różnice, który ujawnia prawdziwy błąd? Na koniec sprawdź, czy jeden z wygenerowanych testów zadziałał, dodając celowy błąd do kodu i wyświetlając przerwę w teście.
lista kontrolna
- [ ] Rozróżniam, czy test ma na celu naprawę, czy weryfikację zachowania.
- [ ] Kiedy proszę o test, podaję regułę (specyfikację), która powinna obowiązywać, a nie kod.
- [ ] Każde wygenerowane twierdzenie porównuję ze specyfikacją.
- [ ] Wyraźnie żądam przypadków brzegowych i awarii.
- [ ] Postrzegam procentowe pokrycie jako narzędzie, a nie cel.
- [ ] Sprawdzam, czy test rzeczywiście chroni, wstrzykiwając błędy.