Premiera / Narzędzie
Testy pisze już AI. TypeMock chce sprawdzać, które z nich mają sens
Skoro asystenci AI generują testy jednostkowe szybciej, niż ktokolwiek zdąży je przejrzeć, TypeMock ogłosił 22 czerwca narzędzie Test Review, które ma wskazywać, które z nich warto trzymać. Zamiast czytać sam kod, obserwuje testy w trakcie wykonania: ile kodu realnie dotykają i czy nie ukrywają zależności od plików czy sieci, które stoją za migającymi testami. Założyciel Eli Lopian ujmuje to wprost: przechodzący test nie jest automatycznie przydatny. Diagnoza jest trafna, ale to wciąż zapowiedź producenta, którą trzeba sprawdzić na własnym kodzie.
Napisała AI, żeby oszczędzić Ci czytania setek źródeł. · Jak to działa
Premiera / Narzędzie · 4 min ·
Przez ostatnie lata problemem było napisanie wystarczającej liczby testów jednostkowych, tych małych sprawdzianów, które uruchamia się przy każdej zmianie kodu, żeby upewnić się, że pojedyncza funkcja nadal robi to, co powinna. Pisanie ich ręcznie jest żmudne, więc deweloperzy chętnie oddali tę robotę asystentom AI. I tu pojawia się nowy kłopot: kiedy testy generuje model, przybywa ich szybciej, niż ktokolwiek jest w stanie je przejrzeć, a połowa z nich może nie sprawdzać niczego sensownego. TypeMock, firma od lat zajmująca się narzędziami do testów jednostkowych dla platformy .NET, ogłosiła 22 czerwca nowe narzędzie o nazwie Test Review, które ma odpowiadać właśnie na to pytanie: które z tych wygenerowanych testów w ogóle warto trzymać.
Problem nie jest już w tym, ile testów masz, tylko które są warte utrzymania
Najlepiej ujął to sam założyciel firmy. "Przez lata branża skupiała się na tworzeniu większej liczby testów", powiedział Eli Lopian, założyciel i prezes TypeMock. "Dziś wyzwaniem jest zrozumienie, które testy zasługują na istnienie. Przechodzący test nie jest automatycznie testem przydatnym." To zdanie jest sednem całej sprawy. Test, który zawsze kończy się na zielono, wygląda na sukces, ale jeśli sprawdza coś trywialnego albo dubluje inny test, to tylko wydłuża czas każdego uruchomienia i daje fałszywe poczucie, że kod jest dobrze pokryty testami. Lopian nazywa to wprost: takie testy nie zwiększają pewności, zwiększają tylko koszt utrzymania.
Czytaj dalej za darmo
Podaj e-mail, aby odblokować pełną treść i cały serwis. Zapiszemy Cię do newslettera.