Oddzielne raporty zasięgu kodu dla testów jednostkowych i integracyjnych, czy jeden raport dla obu?

Czy powinien istnieć osobny raport dotyczący pokrycia kodu dla testów jednostkowych i integracji, czy jeden raport pokrycia kodu dla obu?

Założeniem tego jest to, że pokrycie kodu pozwala nam upewnić się, że nasz kod został objęty testami tak dalece, jak to możliwe (tyle, ile może teraz maszyna).

Posiadanie osobnego raportu jest dla nas wygodniejsze, aby wiedzieć, co nie zostało objęte testami jednostkowymi, a co nie zostało uwzględnione w testach integracyjnych. Ale w ten sposób nie widzimy procentu całkowitego pokrycia.

Przede wszystkim musisz mieć i analizować łączny (całkowity) zasięg. Jeśli się nad tym zastanowić, jest to najbardziej naturalny sposób, aby właściwie ustalić priorytety ryzyka i skoncentrować wysiłki na rozwoju testów.

Połączone pokrycia pokazuje co kod nie jest objęte testami w ogóle , czyli jest najbardziej ryzykowne i powinny być badane w pierwszej kolejności. Oddzielne raporty zasięgu nie pomogą tutaj, ponieważ nie pozwalają dowiedzieć się, czy kod jest testowany w inny sposób, czy w ogóle nie jest testowany.

Przydatna może być również oddzielna analiza zasięgu, ale lepiej byłoby to zrobić po zakończeniu analizy połączonej i najlepiej obejmowałaby również wyniki analizy połączonego zasięgu.

Cel oddzielnej analizy zasięgu różni się od analizy łączonej. Oddzielna analiza pokrycia pomaga ulepszyć projekt twojego zestawu testów, w przeciwieństwie do analizy połączonego pokrycia, która ma decydować o testach, które zostaną opracowane bez względu na wszystko.

„Och, ta luka nie jest uwzględniona tylko dlatego, że zapomnieliśmy dodać ten prosty test jednostkowy (integracyjny) do naszego pakietu jednostkowego (integracyjnego), dodajmy go” - osobne pokrycie i analiza jest tutaj najbardziej przydatne, ponieważ w połączeniu można ukryć luki które chcesz pokryć w konkretnym apartamencie.

Z powyższej perspektywy nadal pożądane jest jednak posiadanie wyników połączonej analizy zasięgu w celu analizy trudniejszych przypadków. Pomyśl o tym, dzięki tym wynikom Twoje decyzje dotyczące rozwoju testów mogą być bardziej wydajne dzięki posiadaniu informacji o pakietach testowych „partnerów”.

„Jest tutaj luka, ale opracowanie testu jednostkowego (integracji) na jej pokrycie byłoby naprawdę kłopotliwe, jakie są nasze opcje? Sprawdźmy łączny zasięg ... och, jest już objęty w innym miejscu, to znaczy, że pokrycie go w naszym pakiecie nie jest krytycznie ważne ”.

Nie wspominasz o swoim narzędziu testowym. Wiele z nich ma funkcje „łączenia”, które pozwalają agregować wyniki wielu przebiegów lub pakietów. Jeśli chcesz zagregować wskaźnik pokrycia, zapoznaj się z funkcją łączenia w swoim narzędziu pokrycia.

Czy możemy teraz rozmawiać o słoniu w pokoju?

Nie ma łyżki. I nie ma „procentu całkowitego pokrycia”. Przynajmniej żaden prosty.

Procent pokrycia to łatwo zrozumiały wskaźnik, który pomaga zrozumieć zakres, głębokość i zakres pakietów testowych. Ale jak w przypadku każdego prostego testu porównawczego, bardzo łatwo jest zostać celem skupionym na tej wartości jako rodzaj magicznego talizmanu „pełnego testowania”.

Powiedzmy, że osiągnąłeś chwałę „100% pokrycia testowego”. Tak! Ale co to znaczy? 100% linii kodu jest testowanych, prawda? A co z tą linią?

launch_missile = launch_authorized and launch_cmd_given else previous_launch_status

„Zakrycie” tej linii oznacza coś - ale nie wiele, ponieważ istnieje wiele warunków, które są Truelub Falsez pewnym prawdopodobieństwem, ale jest mało prawdopodobne, że przetestowałeś wszystkie kombinacje tych warunków. Nawet jeśli ta linia jest pokrywana kilkanaście razy, jeśli jeden z warunków jest stosunkowo rzadki, nie zbliżyłeś się do przetestowania wszystkich prawdziwych wyników, które mogą wystąpić w praktyce. Aby to wyjaśnić, bardziej syntetyczny przykład:

engage_laser = (laser_armed and safety_disengaged) or random.random() < 0.0000003

Ile razy musiałbyś pokryć tę linię, aby naprawdę wyczerpująco ją przetestować? Ile razy musiałbyś to obejmować, aby przetestować to w połączeniu ze wszystkimi innymi zmiennymi w programie (z ich własnymi, prawdopodobnie podobnie rzadkimi) prawdopodobieństwami?

Nie twierdzę, że wskaźniki zasięgu są bezużyteczne. Są naprawdę świetne . Koncentrują się na jednym z kluczowych zagadnień: w jakim stopniu mój system oprogramowania jest testowany? Pomagają przejść od „mamy kilka testów” do „dokładnie przetestowaliśmy”.

Ale podczas pracy nad „połączonymi wynikami”, rzeczywistość jest taka, że ​​twój wynik zwykle będzie dotyczył „pokrycia wypowiedzi”, a nie „warunku”, „orzeczenia” lub „ścieżki” . Tak więc niezależnie od liczby, jaką dają Ci sumaryczne wyniki, jest mało prawdopodobne, że daje prawdziwy obraz tego, jak wiele potencjalnych stanów i kombinacji stanów jest testowanych. Podczas pracy nad zwiększeniem procentu pokrycia, rozważ również zmierzenie pokrycia predykatem. Zapewni to bardziej realistyczny - i niemal zawsze bardziej otrzeźwiający - pogląd na rozległość testu.