Automatyczne generowanie testów

0

Cześć wszystkim,

Zgłębiam ostatnio temat automatycznego generowania testów jednostkowych na podstawie kodu. Osobiście akurat skupiam się wokół IntelliTest (rozwiązanie dla .Net) ale chciałbym poruszyć temat bardziej ogólnie (możecie podać jakieś narzędzia z innych jezyków z jakimi mieliście styczność / wrażenie z ich korzystania).

Czy korzystacie z czegoś takiego albo podobnego zawodowo?* (osobiście nie miałem okazji ale wyobrażam sobie zastosowanie takiego narzędzia np. jak dostajemy do modyfikacji już działający kod bez testów, wiem wiem wszyscy piszemy testy przed kodem TDD pełną parą ale spróbujcie sobie wyobrazić że jednak tych testów nie ma, i zanim zaczniemy coś modyfikować fajnie by było go pokryć testami aby nie zepsuć tego co już działa, i w tym wypadku zamiast odkrywkowo pisać takie testy można by było je wygerować, pogrzebać w kodzie zobaczyć co np. przestanie działać)* -> może jakieś inne zastosowania takich narzędzi?

Co sądzicie o przypadku gdy cały test jest wygenerowany, vs np. generowany tylko jego fragment, sugerowane Assercje czy automatycznie wygenerowane tylko Mocki? (albo jakiś inny fragment)

Akurat tutaj poruszam temat testów jednostkowych bo dotyczą najmniejszych fragmentów (więc w teorii łatwiej takie testy wygenerować nie trzeba znać kontekstu), ale czy takie automatyczne generowanie ma racje bytu przy testach integracyjnych, interfejsu (tutaj się nie znam moze są już jakieś narzędzia), testach E2E (tu chyba by trzeba było określać jakieś checkpointy w sposób sformalizowany jakie ma spełnić)?

0

Nie sądzę, aby tak automatycznie wygenerowane testy miały jakąś większą wartość. Ok, mogą pokryć ścieżki i różne warunki brzegowe, o których programista może zapomnieć, ale bez kontekstu domenowego wygenerują też mnóstwo śmieci, które będą testowały rzeczy nie mające szans wystąpić, a z drugiej strony nie wygenerują wielu testów faktycznie coś sprawdzających.

0

Jakieś 2 lata temu robiłem research na temat Model Based Testing. Koncepcja polega na generowaniu testów na podstawie opisu formalnego, zwykle maszyny stanów. Badaliśmy kilka rozwiązań dla Javy i C#. Jedno nazywało się OSMO (to było jak dla mnie najciekawsze spośród darmowych), pozostałych nie pamiętam. Generalnie wniosek był taki, że darmowe narzędzia są w powijakach (choć funkcjonalne w podstawowym zakresie) i nikt nie da kasy na rozwijanie tego, a jedno profesjonalne rozwiązanie kosztuje horrendalne pieniądze. :) Czy jest to użyteczne w sumie nie wiem. Dla mnie na pewno nie, bo w życiu nie projektowałem oprogramowania w ten sposób, ale jeśli ktoś tak robi i nie ma za dużych wymagań (lub głęboką kieszeń) to jak najbardziej warto spróbować.

0

Właśnie zauważyłem że takie narzędzia nie są dosyć popularne, natomiast temat wydaje mi się dosyć ciekawy. Dlatego chcę pozbierać opinie uwagi i wszystko co się może przydać. Zastanawia mnie właśnie czy brak narzędzi może być spowodowany poziom zaawansowaia tematu (nieukrywajmy napisanie czegos takiego to nie klepanie formatek), temat z tego co zauważyłem jest głównie poruszany czysto jako reseach.

Interesują mnie takie ogólne rozważania (bo tutaj na pewno jest sporo ludzi mądrzejszych ode mnie, których spojrzenie na temat będzie na pewno pomocne) żeby w przyszłości może spróbuję ruszyć z tym tematem jako projekt opensource.

@somekind zgadzam się że te testy będą generować masę śmieci, ale jeśli byśmy generowali tylko powiedzmy część testów właśnie z sytuacjami brzegowymi typu jakieś MaxInt na wejściu czy testy dla rzucanych wyjątków, testy dla wszystkich możliwych ścieżek przepływów sterowania. Te testy też nie muszą być pięknie wygenerowane raczej programista poza sytuacjami awaryjnymi by tam nie zaglądał (sam nie lubię się babrać w generowanym kodzie). Z drugiej strony takie testy moga się na nic nie przydać.

@elwis dzięki, właśnie o takie przemyślenia czy buzz wordy, nazwy narzędzi mi chodziło, zerknę na to :D

0

Myślę, że te narzędzia są mało popularne ze względu na ogólny kształt przemysłu, który broni się jak może przed czymkolwiek sensownym. Poza tym myślę, że wiele na rzeczy ma silna separacja programistów od inżynierów testów. Taki inżynier testów musiałby samemu spędzić wiele czasu jako regularny programista, żeby zdobyć know-how jak wprowadzić w życie nowy sposób testowania. Natomiast programista, który nie jest odpowiedzialny za całokształt testowania ma to gdzieś, a prawda jest taka: nie potrzebujesz — nie zrobisz.
BTW. Wiem, że to nie jest automatyczne generorowanie, ale jest to dość ciekawe podejście do testowania, mianowanicie fuzzery, nie wiem czy słyszałeś. Używa się głównie w testowaniu bezpieczeństwa. Nie jest to nowa koncepcja w sumie jak czytam, ale ostatnio zdaje się przeżywa renesans.

1 użytkowników online, w tym zalogowanych: 0, gości: 1