Czym jest pokrycie kodu i jak je mierzyć?

Pokrycie kodu zasadniczo sprawdza, ile kodu jest objęte testami. Tak więc, jeśli masz 90% pokrycia kodu, oznacza to, że 10% kodu nie jest objęte testami. Wiem, że możesz myśleć, że 90% kodu jest objęte, ale musisz spojrzeć z innej perspektywy. Co cię powstrzymuje, aby uzyskać 100% pokrycie kodu?

Dobrym przykładem będzie to:

if(customer.IsOldCustomer()) 
{
}
else 
{
}

W powyższym kodzie są dwie ścieżki/gałęzie. Jeśli zawsze uderzasz w gałąź "tak" następnie nie pokrywasz części else i zostanie ona pokazana w wynikach pokrycia kodu. Jest to dobre, ponieważ teraz wiesz, że to, co nie jest objęte i można napisać test na pokrycie części else. Jeśli nie było pokrycia kodu, to po prostu siedzisz na bombie zegarowej, aby eksplodować.

NCover {[9] } jest dobrym narzędziem do pomiaru pokrycia kodu.

Pamiętaj, że "100% pokrycie kodu" nie oznacza, że wszystko jest testowane całkowicie - chociaż oznacza to, że każda linia kodu jest testowana, nie oznacza to, że są testowane w każdej (wspólnej) sytuacji..

Użyłbym code-coverage, aby wyróżnić fragmenty kodu, dla których powinienem pisać testy. Na przykład, jeśli jakiekolwiek narzędzie do pokrycia kodu pokazuje, że myImportantFunction () nie jest wykonywane podczas uruchamiania moich obecnych testów jednostkowych, prawdopodobnie powinny one zostać ulepszone.

W zasadzie 100% pokrycie kodu nie oznacza, że Twój kod jest idealny. Użyj go jako przewodnika do pisania bardziej kompleksowych (jednostkowych)testów.

Uzupełnienie kilku punktów do wielu poprzednich odpowiedzi:

Pokrycie kodu oznacza, jak dobrze twój zestaw testowy pokrywa kod źródłowy. tzn. w jakim stopniu kod źródłowy jest objęty zestawem przypadków testowych.

Jak wspomniano w powyższych odpowiedziach, istnieją różne kryteria pokrycia, takie jak ścieżki, warunki, funkcje, instrukcje itp. Ale dodatkowe kryteria, które należy uwzględnić to

1. zasięg warunku: wszystkie wyrażenia logiczne, które mają być ocenione pod kątem true i fałsz.
2. Decision coverage: nie tylko wyrażenia logiczne, które mają być ocenione raz na true I false, ale także wszystkie kolejne ciała if-elseif-else.
3. pokrycie pętli: oznacza, że każda możliwa pętla została wykonana jeden raz, więcej niż raz i czas zerowy. Ponadto, jeśli mamy założenie na maksymalny limit, to, jeśli jest to możliwe, przetestuj maksymalne czasy graniczne i, o jeden więcej niż maksymalne czasy graniczne.
4. pokrycie wejścia i wyjścia: Test dla wszystkich możliwych połączeń i ich wartości zwrotnej.
5. parametr Pokrycie wartości (PVC). Aby sprawdzić, czy wszystkie możliwe wartości dla parametru są testowane. Na przykład, łańcuch może być jednym z tych powszechnie: A) null, B) empty, C) whitespace (spacja, tabs, nowa Linia), D) valid string, e) invalid string, f) single-bajt string, g) double-bajt string. Nie przetestowanie każdej możliwej wartości parametru może spowodować błąd. Testowanie tylko jednej z nich może skutkować 100% pokryciem kodu, ponieważ każda linia jest pokryta, ale ponieważ tylko jedna z siedmiu opcji jest testowana, oznacza to, że tylko 14,2% pokrycia wartości parametru.
6. pokrycie dziedziczenia: w przypadku źródła zorientowanego obiektowo, zwracając Pochodny obiekt, o którym mowa w klasie bazowej, należy sprawdzić pokrycie do oceny, jeśli zwracany jest obiekt rodzeństwa.

Uwaga: statyczna analiza kodu stwierdzi, czy istnieje jakiś kod nieosiągalny lub wiszący, tj. kod nie objęty żadnym innym wywołaniem funkcji. A także inne pokrycia statyczne. Nawet jeśli statyczna analiza kodu donosi, że 100% kod jest objęty, nie daje raportów o twój zestaw testowy, jeśli wszystkie możliwe pokrycie kodu jest testowany.

Zakres kodu został dobrze wyjaśniony w poprzednich odpowiedziach. Więc to jest bardziej odpowiedź na drugą część pytania.

Użyliśmy trzech narzędzi do określenia zasięgu kodu.

1. JTest - autorskie narzędzie zbudowane w oparciu o JUnit. (Generuje również testy jednostkowe.)
2. Cobertura - open source code coverage tool, które można łatwo połączyć z testami JUnit w celu generowania raportów.
3. Emma - inny - ten, którego użyliśmy w nieco innym celu niż testowanie jednostkowe. Został on użyty do generowania raportów pokrycia, gdy aplikacja internetowa jest dostępna dla użytkowników końcowych. To w połączeniu z narzędziami do testowania sieci (przykład: Canoo) może dać bardzo przydatne raporty dotyczące zasięgu, które mówią, ile kodu jest pokryte podczas typowego użytkowania użytkownika końcowego.

Używamy tych narzędzi do

• recenzja, że programiści napisali dobre testy jednostkowe
• Upewnij się, że cały kod jest przesuwany podczas czarnej skrzynki testowanie

Pokrycie kodu jest po prostu miarą testowanego kodu. Istnieje wiele kryteriów pokrycia, które można zmierzyć, ale zazwyczaj są to różne ścieżki, warunki, funkcje i oświadczenia w programie, które składają się na całkowity zasięg. Metryka pokrycia kodu to tylko procent testów, które wykonują każde z tych kryteriów pokrycia.

Jeśli chodzi o śledzenie zasięgu testów jednostkowych w moich projektach, używam statycznych narzędzi do analizy kodu, aby śledzić.

Dla Perla jest doskonały Moduł Devel::Cover , którego regularnie używam na swoich modułach.

Jeśli budowanie i instalacja jest zarządzana przez Module:: Build, możesz po prostu uruchomić ./Build testcover, aby uzyskać ładną stronę HTML, która mówi o zasięgu dla sub, linii i warunku, z ładnymi kolorami ułatwiającymi sprawdzenie, która ścieżka kodu nie została pokryta.