Opublikowano We wpisie o pokryciu kodu (Code Coverage) napisałem: Należy pamiętać, że to są narzędzia dla programisty Co przez to rozumiem? Code Coverage nie może być używany przez kierownictwo/zarząd/management/etc – a już pod żadnym pozorem nie może być związany finansowo z wypłatą programisty. Dlaczego? Przyciśnięty programista może bardzo łatwo wygenerować dowolne pokrycie kodu i to przy dosyć małej ilości pracy. Pisząc odpowiednią ilość testów jednostkowych bez asercji można uzyskać 100% pokryci...
Opublikowano Co to jest CodeCoverage? Jest to pokrycie kolejnych linii kodu testami jednostkowymi. Metryka ta pokazuje ile procent linijek kodu ma przynajmniej jeden test jednostkowy, który ją wykonuje. Sprawa wydaje się prosta, tyle tylko, że w świecie .neta kod kompiluje się do… no właśnie do kodu pośredniego. Dopiero ten kod pośredni jest kompilowany w razie potrzeby do kodu maszynowego. Co więcej o ile nie wprowadzamy zmian do kodu źródłowego, to źródła się nie zmieniają ale już kod kompilowany może...
Pisać testy jednostkowe do wszystkiego? Celować w 100% unit-test-code-coverage? Stosować TDD dla każdego rodzaju kodu? Na te pytania bardzo łatwo znaleźć w internecie odpowiedź i brzmi ona: TAK. Niestety nie jest to odpowiedź prawidłowa. Czasem lepiej testu nie napisać, niż go napisać. Czasem lepiej test skasować, niż go po raz dziesiąty poprawiać po zmianie w kodzie.
W trakcie pisania kodu przyzwyczailiśmy się już do tego, że należy równolegle pisać testy. Podejść, kiedy i jak pisać testy jest wiele. Do wyboru mamy też kilka dostępnych frameworków testowych, ale nie o tym chciałem napisać. W tym artykule chcę poruszyć temat badania pokrycia kodu testami.W trakcie pisania testów niejednokrotnie występuje potrzeba sprawdzenia, które fragmenty kodu pokryte są testami, a które nie.