W mojej pracy zaczynamy naciskać na pokrycie kodu, co skłoniło mnie do myślenia ... Ile wystarcza kodu?

Kiedy dochodzi do zmniejszenia zysków z pokrycia kodu? Jaki jest słaby punkt między dobrym zasięgiem a niewystarczającym? Czy różni się w zależności od rodzaju projektu (np. WPF, WCF, Mobile, ASP.NET) (Piszemy klasy C #).

Dążymy do co najmniej 70%. W przypadku rzeczy, które są łatwiejsze do przetestowania (na przykład funkcjonalne struktury danych), dążymy do 90%, a większość osób dąży do jak najbliższej 100%, jak to możliwe. W przypadku rzeczy związanych z WPF i innych frameworków, które są bardzo trudne do przetestowania, otrzymujemy znacznie mniejszy zasięg (zaledwie 70%).

Uważam, że sam zasięg kodu jest kiepską miarą. Łatwo jest wytworzyć mnóstwo bezużytecznych testów obejmujących kod, ale nie należy odpowiednio sprawdzać wyników lub nie testować na przykład przypadków skrajnych. Kod zakrywający oznacza po prostu, że nie zgłasza wyjątku, nie że jest poprawny. Potrzebujesz testów jakości - ilość nie jest tak ważna.

„Dosyć” ma miejsce, gdy możesz wprowadzać zmiany w kodzie, mając pewność, że niczego nie zepsujesz. W niektórych projektach może to być 10%, w innych może to być 95%.

To prawie nigdy tak wysokie, jak 100%. Czasami jednak próba uzyskania 100% pokrycia kodu może być świetnym sposobem na usunięcie cruft z bazy kodu. Nie zapominaj, że istnieją dwa sposoby na zwiększenie zasięgu kodu - napisz więcej testów lub wyjmij kod. Jeśli kod nie jest objęty, ponieważ jest trudny do przetestowania, istnieje duża szansa, że ​​możesz go uprościć lub zmienić, aby ułatwić testowanie. Jeśli testowanie jest zbyt niejasne, zwykle istnieje duża szansa, że ​​nic innego go nie używa.

Zasięg kodu zbliża się w 100% asymptotycznie. W związku z tym ostatnie 5% to prawdopodobnie więcej wysiłku, niż jest to warte, ponieważ zaczynasz osiągać znikomo małe zwroty za poświęcony wysiłek.

Pokrycie jest metryczny pilnować, ale to nie powinno być ostatecznym celem. Widziałem (i co prawda napisałem!) Dużo kodu o wysokim zasięgu - 100% zasięgu (oczywiście TDD), ale:

• nadal pojawiają się błędy
• projekt może być nadal kiepski
• naprawdę możesz się zabić strzelając do jakiegoś arbitralnego celu - wybierz bitwy: str

Jest to „Droga Testivus” entry że myślę, że należy odwołać się tutaj :)

Tylko 20% większości kodu będzie działać przez 80% czasu . Analiza zasięgu kodu nie jest bardzo przydatna, chyba że w połączeniu z wykresem połączeń w celu ustalenia, co należy przetestować najbardziej. To mówi ci, gdzie prawdopodobnie będą twoje skrzynie. Możesz wymyślić 100 testów tylko dla przypadków skrajnych, które stanowią mniej niż 5% rzeczywistego kodu.

Tak więc upewnij się, że pokrywasz 100% z 20%, które definiują ścieżki krytyczne, i co najmniej 50% reszty (zgodnie z wykresem połączeń). To powinno zapewnić ci (w przybliżeniu) 70% - 75% całkowitego zasięgu, ale jest różna.

Nie marnuj czasu, próbując uzyskać ponad 70% całkowitego zasięgu, pozostawiając krytyczne przypadki bez kontroli.

Użyj zasięgu jako przewodnika, aby wskazać obszary nie testowane. Zamiast mieć mandat na pokrycie, mądrzej jest zrozumieć przyczynę braku kodu. Zapisanie przyczyny niedoboru jest dobrą dyscypliną, która pozwala zrównoważyć ryzyko.

Czasami powód jest mniej niż pożądany „np. Skończył się czas”, ale może być OK dla wczesnego wydania. Lepiej jest oznaczyć obszary, do których można później wrócić, aby zwiększyć zasięg.

Pracuję nad oprogramowaniem do lotów krytycznych, w których 100% pokrycia wyciągów uważa się za odpowiednie dla systemów niekrytycznych. W przypadku bardziej krytycznych systemów sprawdzamy zasięg gałęzi / decyzji i stosujemy technikę MC / DC, która czasem nie jest wystarczająco rygorystyczna.

Musimy również upewnić się, że objęliśmy również kod obiektowy.

Jest to równowaga między ryzykiem, w naszym przypadku bardzo wysokim, w stosunku do wartości / kosztów. Potrzebny jest świadomy wybór w oparciu o ryzyko pominięcia błędu.

Kiedy zaczniesz rozważać zmiany, które wpłyną na wydajność, bezpieczeństwo, elastyczność lub łatwość konserwacji w czasie wykonywania w celu zapewnienia większego pokrycia kodu, czas zakończyć poszukiwania większego pokrycia kodu.

Mam projekty, w których ten punkt wynosi 0%, ponieważ nie można obliczyć zasięgu bez szkody dla projektu i inne projekty, w których jest to aż 92%.

Wskaźniki pokrycia kodu są przydatne tylko do wskazywania, gdybyś mógł przegapić niektóre testy. Nic nie mówią o jakości twoich testów.

Oprogramowanie o znaczeniu krytycznym wymaga 100% pokrycia wyciągów.

Na początku nie ma to sensu. Wszyscy wiedzą, że pełne pokrycie testowe nie oznacza, że ​​kod jest w pełni przetestowany i że uzyskanie 100% zasięgu bez testowania aplikacji nie jest trudne.

Niemniej jednak 100% pokrycia jest dolnym limitem: chociaż 100% pokrycia nie jest dowodem oprogramowania wolnego od błędów, jest pewne, że przy mniejszym pokryciu kod nie jest w pełni testowany i jest to po prostu niedopuszczalne w przypadku oprogramowania o krytycznym znaczeniu dla przestrzeni.

Naprawdę podoba mi się odpowiedź @ RevBingo, ponieważ sugeruje on, że walka o 100% może spowodować wyczyszczenie lub usunięcie nieużywanego kodu. To, czego nie widziałem w innych odpowiedziach, to poczucie, kiedy potrzebujesz wysokiego zasięgu, a kiedy nie. Zacząłem dźgać, zaczynając od tego. Myślę, że dodanie szczegółów do takiej tabeli byłoby bardziej przydatne niż znalezienie jednego numeru zasięgu testu, który byłby odpowiedni dla całego kodu.

100%

W przypadku publicznego interfejsu API, takiego jak Kolekcje java.util, który nie jest sprzężony z bazą danych i nie zwraca HTML, myślę, że 100% pokrycia to szlachetny cel początkowy, nawet jeśli zadowolisz się 90-95% z powodu czasu lub innych ograniczenia. Zwiększenie zasięgu testu po ukończeniu funkcji wymusza bardziej szczegółowy poziom kontroli niż w przypadku innych rodzajów przeglądu kodu. Jeśli Twój interfejs API jest w ogóle popularny, ludzie będą go używać, subklasować, deserializować itd. W sposób, którego nie możesz się spodziewać. Nie chcesz, aby ich pierwsze doświadczenie polegało na znalezieniu błędu lub nadzorowaniu projektu!

90%

W przypadku kodu infrastruktury biznesowej, który pobiera struktury danych i zwraca struktury danych, 100% jest prawdopodobnie dobrym początkowym celem, ale jeśli ten kod nie jest wystarczająco publiczny, aby zachęcić do niewłaściwego użycia, może 85% jest nadal akceptowalne?

75%

W przypadku kodu, który przyjmuje i zwraca ciągi, myślę, że testowanie jednostkowe jest znacznie bardziej kruche, ale może być przydatne w wielu sytuacjach.

50% lub mniej

Nienawidzę pisania testów dla funkcji, które zwracają HTML, ponieważ jest taki kruchy. Co się stanie, jeśli ktoś zmieni CSS, JavaScript lub cały obiekt HTML i angielski, który zwrócisz, nie ma sensu dla użytkowników końcowych? Jeśli możesz znaleźć funkcję, która wykorzystuje dużo logiki biznesowej do tworzenia małego kodu HTML, warto ją przetestować. Ale odwrotna sytuacja może w ogóle nie być warta przetestowania.

Prawie 0%

W przypadku niektórych kodów definicja „poprawna” to „ma sens dla użytkownika końcowego”. Istnieją nietradycyjne testy, które można wykonać na tym kodzie, takie jak automatyczne sprawdzanie gramatyki lub sprawdzanie poprawności danych wyjściowych w formacie HTML. Skonfigurowałem nawet instrukcje grep dla niewielkich niespójności, na które zwykle padamy ofiarą w pracy, na przykład mówiąc „Zaloguj się”, gdy reszta systemu nazywa to „Zaloguj się”. Ten człowiek nie jest ściśle testem jednostkowym, ale jest pomocnym sposobem na wychwycenie problemów bez oczekiwania konkretnej wydajności.

Ostatecznie jednak tylko człowiek może ocenić, co jest rozsądne dla ludzi. Testy jednostkowe nie mogą ci w tym pomóc. Czasami potrzeba kilku ludzi, aby dokładnie to ocenić.

Absolutnie 0%

To smutna kategoria i wydaje mi się, że nie jestem osobą, która by ją pisała. Ale w każdym wystarczająco dużym projekcie są dziury dla królików, które mogą ssać osobiście tygodnie bez żadnych korzyści biznesowych.

Kupiłem książkę, ponieważ twierdziła, że ​​pokazuje, jak automatycznie wyśmiewać dane do testowania Hibernacji. Ale testował tylko zapytania Hibernate HQL i SQL. Jeśli musisz robić dużo HQL i SQL, tak naprawdę nie zyskujesz zalet Hibernacji. Istnieje pewna forma bazy danych Hibernacja w pamięci, ale nie zainwestowałem czasu, aby dowiedzieć się, jak efektywnie wykorzystać ją w testach. Gdybym tak działał, chciałbym mieć wysoki (50% -100%) zasięg testu dla dowolnej logiki biznesowej, która oblicza różne rzeczy, poruszając się po grafie obiektowym, powodując, że Hibernacja uruchamia niektóre zapytania. Moja zdolność do testowania tego kodu jest teraz bliska 0% i to jest problem. Dlatego poprawiam zasięg testów w innych obszarach projektu i staram się preferować funkcje czyste niż te, które mają dostęp do bazy danych, głównie dlatego, że łatwiej jest pisać testy dla tych funkcji. Nadal,

Myślę, że to zależy od części testowanej aplikacji. Np. W przypadku logiki biznesowej lub dowolnego komponentu obejmującego złożone transformacje danych chciałbym objąć zasięgiem 90% (jak najwięcej). Często znajdowałem małe, ale niebezpieczne błędy, po prostu testując jak najwięcej kodu. Wolę znaleźć takie błędy podczas testowania, niż pozwolić, aby wystąpiły one w witrynie klienta rok później. Ponadto dużą zaletą kodu jest to, że uniemożliwia on zbyt łatwą zmianę działającego kodu, ponieważ testy muszą być odpowiednio dostosowane.

Z drugiej strony myślę, że istnieją komponenty, dla których pokrycie kodu jest mniej odpowiednie. Na przykład podczas testowania GUI napisanie testu obejmującego cały kod wykonywany po kliknięciu przycisku w celu wysłania zdarzenia do odpowiednich komponentów jest bardzo czasochłonne. Myślę, że w tym przypadku bardziej efektywne jest zastosowanie tradycyjnego podejścia do ręcznego testu, w którym wystarczy kliknąć przycisk i obserwować zachowanie programu (czy otwiera się właściwe okno dialogowe? Czy wybrane jest właściwe narzędzie ?).

Nie mam tak wysokiej opinii na temat używania pokrycia kodu jako miernika, kiedy twój pakiet testowy ma wystarczający zasięg.

Głównym powodem jest to, że jeśli masz proces, w którym najpierw piszesz jakiś kod, a następnie kilka testów, a następnie patrzysz na pokrycie kodu, aby dowiedzieć się, gdzie przegapiłeś test, to proces wymaga poprawy. Jeśli robisz prawdziwe TDD, masz 100% pokrycie kodu po wyjęciu z pudełka (co prawda, są pewne trywialności, których nie testuję). Ale jeśli spojrzysz na pokrycie kodu, aby dowiedzieć się, co przetestować, prawdopodobnie napiszesz nieprawidłowe testy.

Jedyną rzeczą, którą można wyciągnąć z zakresu kodu, jest to, że jeśli jest on zbyt niski, nie ma wystarczającej liczby testów. Ale jeśli jest wysoki, nie ma gwarancji, że masz wszystkie odpowiednie testy.