Jak się odpala normalny coverage (czy to line coverage, branch coverage, path coverage czy jeszcze inne), to schemat jest ten sam: jeśli kawałek kodu został uruchomiony podczas testu - to jest oznaczany jako covered.
Ale np. w PhpUnit i paru innych frameworkach do testów, jest tak funkcja jak ekskluzja pokrycia. I to działa tak, że można adnotacją albo configiem, per test albo per suite oznaczyć listę klas "do pokrycia". I to działa w ten sposób, że te klasy które nie są oznaczone jako "do pokrycia" mają ustawione na sztywno zawsze 0% covered; a te które są oznaczone jako "do pokrycia", to mają tam coverege gdzie faktycznie kod się odpalił.
Oczywiście, to jest i tak marna metoda sprawdzania przetestowania kodu - wiadomo ze TDD jest lepsze, a coverege nie jest żadnym (przynajmniej dla mnie) wyznacznikiem tego jak coś jest przetestowane. To się rozumie samo przez się, nie o tym jest wątek.
Wątek, chciałem zadać z innego powodu:
- z jednej strony to jest fajne, bo zawężając taką ekslusją niwelujemy przypadkowe covergae (że jakaś klasa przy okazji jest odpalona, ale wcale nie jest przetestowana).
- z drugiej strony, co z klasami i funkcjami wewnętrznymi, które są zaenkapsulowane w jakimś rozwiązaniu:
- Albo ich nie oznaczamy, i one są wiecznie ustawione jako uncovered
- Albo je oznaczamy, tylko wtedy łamiemy enkapsulację i chcąc potem zmienić kawałek kodu trzeba pamiętać (albo nie :D) żeby zmienić tą ekslusję.
Czy to narzędzie jest warte łamania takiej enkapsulacji?
KamilAdam napisał(a):
Może offtop już w pierwszym poście, ale co to znaczy
jakaś klasa przy okazji jest odpalona, ale wcale nie jest przetestowana
Chodzi o to że jej funkcje zostały wywołane podczas działania testu, ale nie zostały one należycie (albo wcale) przetestowane. Tzn, zostały uruchomione przy okazji, ale gdyby je zepsuć/usunąć, to żaden test by nie sfailował.