Jeśli miałbyś wprowadzić minimalny procent pokrycia kodu dla testów jednostkowych, być może nawet jako wymóg zatwierdzenia repozytorium, co by to było?

Proszę wyjaśnić, w jaki sposób dotarliście do swojej odpowiedzi (ponieważ jeśli wszystko, co zrobiliście, to wybraliście numer, to mógłbym to zrobić sam;)

Ta proza ​​Alberto Savoia odpowiada dokładnie na to pytanie (w tym całkiem przyjemnie!):

http://www.artima.com/forums/flat.jsp?forum=106&thread=204677

Testivus o pokryciu testowym

Pewnego ranka programista zapytał wielkiego mistrza:

„Jestem gotowy napisać kilka testów jednostkowych. W jakim zakresie kodu powinienem dążyć? ”

Wielki mistrz odpowiedział:

„Nie martw się zasięgiem, po prostu napisz kilka dobrych testów”.

Programista uśmiechnął się, ukłonił i wyszedł.

...

Później tego samego dnia drugi programista zadał to samo pytanie.

Wielki mistrz wskazał na garnek z wrzącą wodą i powiedział:

„Ile ziaren ryżu powinienem włożyć do tego garnka?”

Zaskoczony programista odpowiedział:

„Jak mogę ci powiedzieć? To zależy od tego, ile osób musisz karmić, jak bardzo są głodni, jakie inne jedzenie podajesz, ile masz ryżu i tak dalej. ”

„Dokładnie” - powiedział wielki mistrz.

Drugi programista uśmiechnął się, ukłonił i wyszedł.

...

Pod koniec dnia przyszedł trzeci programista i zadał to samo pytanie dotyczące pokrycia kodu.

„Osiemdziesiąt procent i nie mniej!” Odpowiedział mistrz surowym głosem, waląc pięścią w stół.

Trzeci programista uśmiechnął się, ukłonił i wyszedł.

...

Po tej ostatniej odpowiedzi młody uczeń podszedł do wielkiego mistrza:

„Świetny mistrzu, dziś słyszałem, że odpowiadasz na to samo pytanie dotyczące pokrycia kodu trzema różnymi odpowiedziami. Dlaczego?"

Wielki mistrz wstał z krzesła:

„Chodź ze mną na świeżą herbatę i porozmawiajmy o tym”.

Po napełnieniu filiżanek gorącą zieloną herbatą wielki mistrz zaczął odpowiadać:

„Pierwszy programista jest nowy i dopiero zaczyna testowanie. W tej chwili ma dużo kodu i żadnych testów. Przed nim jeszcze długa droga; skupienie się teraz na pokryciu kodu byłoby przygnębiające i zupełnie bezużyteczne. Lepiej, żeby przyzwyczaił się do pisania i przeprowadzania testów. Później może się martwić o zasięg. ”

„Z drugiej strony drugi programista ma duże doświadczenie zarówno w programowaniu, jak i testowaniu. Kiedy odpowiedziałem, pytając ją, ile ziaren ryżu powinienem umieścić w garnku, pomogłem jej zrozumieć, że ilość niezbędnych testów zależy od wielu czynników, a ona zna te czynniki lepiej niż ja - w końcu to jej kod . Nie ma jednej, prostej odpowiedzi, a ona jest wystarczająco mądra, aby poradzić sobie z prawdą i pracować z tym. ”

„Rozumiem - powiedział młody uczeń - ale jeśli nie ma jednej prostej odpowiedzi, to dlaczego odpowiedziałeś trzeciemu programistowi„ Osiemdziesiąt procent i nie mniej ”?

Wielki mistrz zaśmiał się tak głośno i głośno, że jego brzuch, dowód, że pił więcej niż tylko zieloną herbatę, opadał w górę iw dół.

„Trzeci programista chce tylko prostych odpowiedzi - nawet jeśli nie ma prostych odpowiedzi… a potem i tak ich nie stosuje”.

Młody uczeń i siwy wielki mistrz skończyli pić herbatę w kontemplacyjnej ciszy.

Pokrycie kodu jest mylącym wskaźnikiem, jeśli Twoim celem jest pokrycie 100% (zamiast 100% testowania wszystkich funkcji).

• Możesz uzyskać 100%, naciskając raz wszystkie linie. Jednak nadal możesz przeoczyć testowanie określonej sekwencji (ścieżki logicznej), w której trafiają te linie.
• Nie można uzyskać 100%, ale nadal przetestowano wszystkie używane ścieżki kodu 80% / freq. Posiadanie testów, które sprawdzają każdy „wyjątek typu ExceptionTypeX” lub podobny defensywny programator, którego używasz, to „miło mieć”, a nie „trzeba mieć”

Zaufaj więc sobie lub swoim programistom, aby zachowali się rzetelnie i obejmowali każdą ścieżkę poprzez swój kod. Bądź pragmatyczny i nie ścigaj magicznego 100% zasięgu. Jeśli zgłaszasz kod TDD, powinieneś otrzymać 90% pokrycia jako bonus. Użyj pokrycia kodu, aby podświetlić fragmenty kodu, które zostały pominięte (nie powinno się to zdarzyć, jeśli TDD, chociaż ... ponieważ piszesz kod tylko w celu przejścia testu. Żaden kod nie może istnieć bez testu partnera)

Zasięg kodu jest świetny, ale zasięg funkcjonalności jest jeszcze lepszy. Nie wierzę w pisanie każdej linii, którą piszę. Ale wierzę w pisanie w 100% testowej wersji wszystkich funkcji, które chcę zapewnić (nawet w przypadku dodatkowych fajnych funkcji, które przyjechałem ze sobą i które nie były omawiane podczas spotkań).

Nie dbam o to, czy będę miał kod, który nie jest objęty testami, ale dbałbym o to, czy zmienię kod i ostatecznie zachowam się inaczej. Dlatego 100% zakres funkcjonalności jest moim jedynym celem.

Przyjęta odpowiedź ma sens - nie ma jednej liczby, która miałaby sens jako standard dla każdego projektu. Są projekty, które po prostu nie potrzebują takiego standardu. Tam, gdzie przyjęta odpowiedź jest niewystarczająca, moim zdaniem polega na opisaniu, w jaki sposób można podjąć taką decyzję dla danego projektu.

Spróbuję to zrobić. Nie jestem ekspertem w inżynierii testów i chętnie zobaczę bardziej świadomą odpowiedź.

Kiedy należy ustawić wymagania dotyczące zasięgu kodu

Po pierwsze, dlaczego miałbyś narzucić taki standard? Ogólnie rzecz biorąc, gdy chcesz wprowadzić empiryczne zaufanie do swojego procesu. Co rozumiem przez „pewność empiryczną”? Cóż, prawdziwa poprawność celu . W przypadku większości programów nie możemy tego wiedzieć na wszystkich wejściach, dlatego zgadzamy się z twierdzeniem, że kod jest dobrze przetestowany . Jest to bardziej poznawalne, ale wciąż jest subiektywnym standardem: zawsze będzie można dyskutować, czy go osiągnąłeś. Debaty te są przydatne i powinny się odbyć, ale także ujawniają niepewność.

Pokrycie kodu jest obiektywnym pomiarem: gdy zobaczysz raport pokrycia, nie będzie wątpliwości, czy standardy zostały spełnione. Czy to dowodzi poprawności? Wcale nie, ale ma wyraźny związek z tym, jak dobrze przetestowano kod, co z kolei jest naszym najlepszym sposobem na zwiększenie pewności co do jego poprawności. Pokrycie kodu jest mierzalnym przybliżeniem niezmiernych cech, na których nam zależy.

Niektóre szczególne przypadki, w których posiadanie standardu empirycznego może przynieść wartość dodaną:

• Aby zadowolić interesariuszy. W przypadku wielu projektów istnieją różne podmioty zainteresowane jakością oprogramowania, które mogą nie być zaangażowane w codzienne opracowywanie oprogramowania (menedżerowie, kierownicy techniczni itp.) Mówiąc „napiszemy wszystko testy, których naprawdę potrzebujemy ”nie są przekonujące: albo muszą całkowicie ufać, albo weryfikować przy ciągłym ścisłym nadzorze (zakładając, że mają nawet techniczną wiedzę, aby to zrobić.) Zapewnienie mierzalnych standardów i wyjaśnienie, w jaki sposób uzasadnione przybliżenie rzeczywistych celów jest lepsze.
• Aby znormalizować zachowanie zespołu. Poza stronami zainteresowanymi, jeśli pracujesz w zespole, w którym wiele osób pisze kod i testy, jest miejsce na dwuznaczność tego, co kwalifikuje się jako „dobrze przetestowane”. Czy wszyscy twoi koledzy mają takie samo pojęcie o tym, jaki poziom testowania jest wystarczająco dobry? Prawdopodobnie nie. Jak to pogodzisz? Znajdź wskaźnik, na który wszyscy się zgodzicie, i zaakceptuj go jako rozsądne przybliżenie. Jest to szczególnie (ale nie wyłącznie) przydatne w dużych zespołach, w których liderzy mogą na przykład nie mieć bezpośredniego nadzoru nad młodszymi programistami. Liczą się także sieci zaufania, ale bez obiektywnych pomiarów zachowanie grupy może stać się niespójne, nawet jeśli wszyscy działają w dobrej wierze.
• Aby zachować uczciwość. Nawet jeśli jesteś jedynym programistą i jedynym interesariuszem swojego projektu, możesz mieć pewne cechy oprogramowania. Zamiast dokonywać bieżących subiektywnych ocen tego, jak dobrze przetestowane jest oprogramowanie (co wymaga pracy), możesz użyć pokrycia kodu jako rozsądnego przybliżenia i pozwolić, aby maszyny dokonały jego pomiaru.

Których wskaźników użyć

Pokrycie kodu nie jest pojedynczą miarą; istnieje kilka różnych sposobów pomiaru zasięgu. To, na którym możesz ustawić standard, zależy od tego, czego używasz w celu spełnienia tego standardu.

Użyję dwóch typowych wskaźników jako przykładów, kiedy możesz je wykorzystać do ustalenia standardów:

• Zakres wyciągów : Jaki procent wyciągów wykonano podczas testowania? Przydatne, aby zorientować się w fizycznym pokryciu twojego kodu: Ile kodu, który napisałem, faktycznie przetestowałem?
  • Ten rodzaj pokrycia obsługuje słabszy argument dotyczący poprawności, ale jest również łatwiejszy do osiągnięcia. Jeśli używasz tylko pokrycia kodu, aby upewnić się, że wszystko jest testowane (a nie jako wskaźnik jakości testu poza tym), to pokrycie instrukcji jest prawdopodobnie wystarczające.
• Zasięg gałęzi : czy istnieje logika rozgałęziania (np. An if), czy oceniono obie gałęzie? To daje lepsze zrozumienie logicznego zasięgu twojego kodu: Ile możliwych ścieżek może obrać mój kod po przetestowaniu?
  • Ten rodzaj pokrycia jest znacznie lepszym wskaźnikiem, że program został przetestowany na obszernym zestawie danych wejściowych. Jeśli używasz pokrycia kodu jako najlepszego empirycznego przybliżenia dla pewności co do poprawności, powinieneś ustanowić standardy na podstawie pokrycia oddziału lub podobnego.

Istnieje wiele innych wskaźników (pokrycie linii jest podobne do pokrycia wyciągu, ale daje na przykład różne wyniki liczbowe dla wyciągów wieloliniowych, na przykład; pokrycie warunkowe i pokrycie ścieżki jest podobne do pokrycia gałęzi, ale odzwierciedla bardziej szczegółowy widok możliwych permutacji wykonanie programu, które możesz napotkać).

Jaki procent wymagać

Na koniec wróć do pierwotnego pytania: Jeśli ustalisz standardy pokrycia kodu, jaka powinna być ta liczba?

Mam nadzieję, że w tym momencie jest jasne, że mówimy o przybliżeniu na początku, więc każda liczba, którą wybierzemy, będzie z natury przybliżona.

Niektóre liczby, które można wybrać:

• 100% . Możesz to wybrać, ponieważ chcesz mieć pewność, że wszystko zostało przetestowane. Nie daje to żadnego wglądu w jakość testu, ale mówi, że jakiś test jakiejś jakości dotknął każdego stwierdzenia (lub oddziału itp.) Ponownie, to wraca do stopnia pewności: jeśli twoje pokrycie jest poniżej 100% , wiesz , że część podzbioru twojego kodu jest nieprzetestowana.
  • Niektórzy mogą twierdzić, że jest to głupie i powinieneś testować tylko te części kodu, które są naprawdę ważne. Twierdziłbym, że powinieneś również zachować tylko te części kodu, które są naprawdę ważne. Zasięg kodu można poprawić, usuwając również niesprawdzony kod.
• 99% (lub 95%, inne liczby z wysokich lat dziewięćdziesiątych). Odpowiednie w przypadkach, gdy chcesz przekazać poziom pewności podobny do 100%, ale zostaw sobie margines, aby nie martwić się o trudny do przetestowania zakątek kod.
• 80% . Widziałem tę liczbę kilka razy i nie do końca wiem, skąd pochodzi. Myślę , że może to być dziwne sprzeniewierzenie zasady 80-20; ogólnie rzecz biorąc, chodzi tutaj o pokazanie, że większość kodu jest testowana. (Tak, 51% byłoby również „najbardziej”, ale 80% lepiej odzwierciedla to, co większość ludzi rozumie przez większość). Jest to właściwe w przypadkach, gdy „dobrze przetestowane” nie ma wysokiego priorytetu (nie nie chcesz marnować wysiłku na testy o niskiej wartości), ale jest to na tyle priorytet, że nadal chciałbyś mieć jakiś standard.

Nie widziałem liczb poniżej 80% w praktyce i trudno mi sobie wyobrazić przypadek, w którym można by je ustawić. Rolą tych standardów jest zwiększenie pewności co do poprawności, a liczby poniżej 80% nie budzą szczególnego zaufania. (Tak, jest to subiektywne, ale znowu chodzi o to, aby dokonać subiektywnego wyboru raz, kiedy ustanawiasz standard, a następnie użyć obiektywnego pomiaru w przyszłości.)

Inne notatki

Powyższe zakłada, że ​​celem jest poprawność. Pokrycie kodu to tylko informacja; może to odnosić się do innych celów. Na przykład, jeśli obawiasz się o łatwość konserwacji, prawdopodobnie zależy ci na luźnym sprzężeniu, co można wykazać testowalnością, którą z kolei można zmierzyć (w niektórych modach) pokryciem kodu. Zatem standard pokrycia kodu stanowi empiryczną podstawę do przybliżenia jakości „łatwości konserwacji”.

Mój ulubiony kod to 100% z gwiazdką. Gwiazdka pojawia się, ponieważ wolę używać narzędzi, które pozwalają mi oznaczać niektóre linie jako linie „nie liczące się”. Jeśli pokryłem 100% linii, które się „liczą”, jestem skończony.

Podstawowym procesem jest:

1. Piszę testy, aby wykonać wszystkie funkcje i przypadki, o których mogę pomyśleć (zwykle na podstawie dokumentacji).
2. Korzystam z narzędzi pokrycia kodu
3. Badam wszystkie linie lub ścieżki, które nie są objęte, i te, które uważam za nieistotne lub nieosiągalne (z powodu programowania obronnego) zaznaczam jako nie liczące się
4. Piszę nowe testy, aby pokryć brakujące linie i poprawić dokumentację, jeśli te przypadki brzegowe nie są wymienione.

W ten sposób, jeśli ja i moi współpracownicy dodamy nowy kod lub zmienimy testy w przyszłości, istnieje jasna linia, która mówi nam, czy coś przeoczyliśmy - zasięg spadł poniżej 100%. Zapewnia również elastyczność w radzeniu sobie z różnymi priorytetami testowania.

Chciałbym mieć kolejną anektodę na temat testu, którym chciałbym się podzielić.

Mamy ogromny projekt, w którym ponad twitter zauważyłem, że przy 700 testach jednostkowych mamy tylko 20% pokrycia kodu .

Scott Hanselman odpowiedział słowami mądrości :

Czy to PRAWO 20%? Czy to 20% odpowiada kodowi, który najbardziej uderzyli twoi użytkownicy? Możesz dodać jeszcze 50 testów i dodać tylko 2%.

Znowu wraca do mojego Testivus na temat odpowiedzi dotyczącej pokrycia kodu . Ile ryżu należy włożyć do garnka? To zależy.

W przypadku dobrze zaprojektowanego systemu, w którym testy jednostkowe napędzały rozwój od samego początku, powiedziałbym, że 85% to dość niska liczba. Małe klasy zaprojektowane do testowania nie powinny być trudne do opisania lepiej.

Łatwo jest odrzucić to pytanie za pomocą:

• Zakryte linie nie są równe testowanej logice i nie należy wczytywać zbyt wiele w procent.

To prawda, ale należy zwrócić uwagę na kilka ważnych kwestii dotyczących pokrycia kodu. Z mojego doświadczenia wynika, że ​​ta metryka jest właściwie bardzo przydatna, jeśli jest właściwie używana. Powiedziawszy to, nie widziałem wszystkich systemów i jestem pewien, że jest ich mnóstwo, w których trudno jest zobaczyć analizę pokrycia kodu dodającą jakąkolwiek rzeczywistą wartość. Kod może wyglądać tak różnie, a zakres dostępnych ram testowych może się różnić.

Ponadto moje rozumowanie dotyczy głównie dość krótkich pętli testowych. Dla produktu, który opracowuję, najkrótsza pętla sprzężenia zwrotnego jest dość elastyczna, obejmując wszystko, od testów klasowych po sygnalizację między procesami. Testowanie dostarczalnego produktu podrzędnego zwykle zajmuje 5 minut, a dla tak krótkiej pętli sprzężenia zwrotnego rzeczywiście można wykorzystać wyniki testu (a konkretnie metrykę pokrycia kodu, na którą tu patrzymy), aby odrzucić lub zaakceptować zatwierdzenia w repozytorium.

Korzystając z metryki pokrycia kodu, nie powinieneś mieć ustalonego (arbitralnego) procentu, który należy spełnić. Takie postępowanie nie daje moim zdaniem prawdziwych korzyści z analizy pokrycia kodu. Zamiast tego zdefiniuj następujące miary:

• Low Water Mark (LWM), najniższa liczba odkrytych linii, jaką kiedykolwiek widziano w badanym systemie
• High Water Mark (HWM), najwyższy procent pokrycia kodu, jaki kiedykolwiek zaobserwowano dla testowanego systemu

Nowy kod można dodać tylko wtedy, gdy nie przekroczymy LWM i nie zejdziemy poniżej HWM. Innymi słowy, nie można zmniejszyć zasięgu kodu i należy go pokryć nowym kodem. Zwróć uwagę, jak mówię, że powinno, a nie musi (wyjaśnione poniżej).

Ale czy to nie oznacza, że ​​nie będzie możliwe usunięcie starych, dobrze przetestowanych śmieci, do których nie będziesz już dłużej potrzebował? Tak i dlatego musisz być pragmatyczny w tych sprawach. Są sytuacje, w których reguły muszą zostać złamane, ale dla twojej typowej codziennej integracji z moich doświadczeń wynika, że ​​te wskaźniki są dość przydatne. Dają one następujące dwie implikacje.

• Kod testowany jest promowany. Dodając nowy kod, naprawdę musisz dołożyć starań, aby kod był testowalny, ponieważ będziesz musiał spróbować pokryć to wszystko swoimi przypadkami testowymi. Testowalny kod jest zwykle dobrą rzeczą.

• Z czasem zasięg testowy starszego kodu rośnie. Dodając nowy kod i nie będąc w stanie objąć go przypadkiem testowym, można zamiast tego spróbować zakodować trochę starszego kodu, aby obejść regułę LWM. To czasami konieczne oszustwo daje przynajmniej pozytywny efekt uboczny, że zasięg starszego kodu wzrośnie z czasem, co sprawia, że ​​pozornie rygorystyczne egzekwowanie tych zasad jest w praktyce bardzo pragmatyczne.

I znowu, jeśli pętla sprzężenia zwrotnego jest zbyt długa, ustawienie czegoś takiego w procesie integracji może być całkowicie niepraktyczne.

Chciałbym również wspomnieć o dwóch innych ogólnych zaletach metryki pokrycia kodu.

• Analiza pokrycia kodu jest częścią dynamicznej analizy kodu (w przeciwieństwie do analizy statycznej, tj. Lint). Problemy wykryte podczas dynamicznej analizy kodu (przez narzędzia takie jak rodzina purify , http://www-03.ibm.com/software/products/en/rational-purify-family ) to takie rzeczy jak niezainicjowane odczyty pamięci (UMR), wycieki pamięci itp. Problemy te można znaleźć tylko wtedy, gdy kod jest objęty wykonanym przypadkiem testowym . Kod, który jest najtrudniejszy do pokrycia w przypadku testowym, to zwykle przypadki nienormalne w systemie, ale jeśli chcesz, aby system zawiódł w sposób płynny (tj. Śledzenie błędów zamiast awarii), możesz zechcieć włożyć trochę wysiłku w pokrycie przypadków nienormalnych także w dynamicznej analizie kodu. Przy odrobinie pecha UMR może doprowadzić do awarii lub pogorszenia się.

• Ludzie są dumni z zachowania 100% nowego kodu, a ludzie dyskutują o testowaniu problemów z podobną pasją jak inne problemy z implementacją. Jak można napisać tę funkcję w bardziej sprawdzalny sposób? Jak poszedłbyś na próbę pokrycia tego nienormalnego przypadku itp.

I negatywne, dla kompletności.

• W dużym projekcie z wieloma zaangażowanymi programistami każdy z pewnością nie będzie geniuszem testowym. Niektóre osoby używają metryki pokrycia kodu jako dowodu, że kod jest testowany i jest to bardzo dalekie od prawdy , jak wspomniano w wielu innych odpowiedziach na to pytanie. To JEDNA miara, która może przynieść dobre korzyści, jeśli jest właściwie używana, ale jeśli jest niewłaściwie używana, może w rzeczywistości prowadzić do złych testów. Poza bardzo cennymi efektami ubocznymi wspomnianymi powyżej, ukryta linia pokazuje tylko, że testowany system może osiągnąć tę linię dla niektórych danych wejściowych i że może zostać wykonany bez zawieszenia lub awarii.

Gdyby to był idealny świat, 100% kodu byłoby objęte testami jednostkowymi. Ponieważ jednak NIE jest to idealny świat, jest to kwestia tego, na co masz czas. W związku z tym zalecam mniejszą koncentrację na określonym odsetku, a bardziej na obszarach krytycznych. Jeśli Twój kod jest dobrze napisany (lub przynajmniej jego uzasadniony faks), powinno być kilka kluczowych punktów, w których interfejsy API są narażone na inny kod.

Skoncentruj swoje wysiłki testowe na tych interfejsach API. Upewnij się, że interfejsy API są 1) dobrze udokumentowane i 2) napisane przypadki testowe pasujące do dokumentacji. Jeśli oczekiwane wyniki nie zgadzają się z dokumentami, oznacza to błąd w kodzie, dokumentacji lub przypadkach testowych. Wszystkie są dobre do sprawdzenia.

Powodzenia!

Wiele sklepów nie docenia testów, więc jeśli jesteś powyżej zera, przynajmniej doceniasz wartość - więc prawdopodobnie niezerowe nie jest złe, ponieważ wiele wciąż jest zerowych.

W świecie .Net ludzie często podają 80% za uzasadnione. Ale mówią to na poziomie rozwiązania. Wolę mierzyć na poziomie projektu: 30% może być w porządku w przypadku projektu interfejsu użytkownika, jeśli masz Selenium itp. Lub testy ręczne, 20% w przypadku projektu warstwy danych może być w porządku, ale 95% + może być całkiem osiągalne dla firmy warstwa reguł, jeśli nie jest to absolutnie konieczne. Tak więc całkowity zasięg może wynosić, powiedzmy, 60%, ale krytyczna logika biznesowa może być znacznie wyższa.

Słyszałem także: aspiruj do 100%, a osiągniesz 80%; ale dąż do 80%, a trafisz 40%.

Konkluzja: Zastosuj regułę 80:20 i pozwól, aby liczba błędów aplikacji poprowadziła Cię.

Pokrycie kodu to tylko kolejna miara. Samo w sobie może to być bardzo mylące (patrz www.thoughtworks.com/insights/blog/are-test-coverage-metrics-overtered ). Dlatego Twoim celem nie powinno być osiągnięcie 100% pokrycia kodu, ale raczej przetestowanie wszystkich odpowiednich scenariuszy aplikacji.

85% byłoby dobrym miejscem startowym dla kryteriów meldowania.

Prawdopodobnie wybrałbym wiele wyższych słupków dla kryteriów wysyłki - w zależności od krytyczności testowanych podsystemów / komponentów.

Korzystam z cobertury i niezależnie od wartości procentowej zalecałbym aktualizowanie wartości w zadaniu sprawdzania cobertury. Co najmniej zwiększaj totallinerate i totalbranchrate do poziomu nieco poniżej obecnego zasięgu, ale nigdy nie obniżaj tych wartości. Do tego zadania należy również przypisać właściwość niepowodzenia kompilacji Ant. Jeśli kompilacja nie powiedzie się z powodu braku zasięgu, znasz kod dodany przez kogoś, ale go nie przetestował. Przykład:

<cobertura-check linerate="0"
                 branchrate="0"
                 totallinerate="70"
                 totalbranchrate="90"
                 failureproperty="build.failed" />

Kiedy myślę, że mój kod nie jest wystarczająco przetestowany jednostkowo i nie jestem pewien, co przetestować w następnej kolejności, używam pokrycia, aby pomóc mi zdecydować, co przetestować w następnej kolejności.

Jeśli zwiększę zasięg w teście jednostkowym - wiem, że ten test jednostkowy jest coś wart.

Dotyczy to kodu, który nie jest objęty, objęty w 50% lub w 97%.

Wolę robić BDD, który wykorzystuje kombinację automatycznych testów akceptacyjnych, ewentualnie innych testów integracyjnych i testów jednostkowych. Pytanie brzmi: jaki powinien być docelowy zasięg zautomatyzowanego zestawu testów jako całości.

Poza tym odpowiedź zależy od metodologii, języka oraz narzędzi testowania i pokrycia. Robiąc TDD w Ruby lub Python, nie jest trudno utrzymać 100% zasięgu i warto to zrobić. Znacznie łatwiej jest zarządzać 100% pokryciem niż 90-procentowy zasięg. Oznacza to, że o wiele łatwiej jest wypełnić luki pokrycia, gdy się pojawiają (a przy wykonywaniu studni TDD luki pokrycia są rzadkie i zwykle warte poświęcenia czasu), niż zarządzanie listą luk pokrycia, których jeszcze nie dotarłeś i których brakuje regresje z powodu stałego tła odkrytego kodu.

Odpowiedź zależy również od historii twojego projektu. Przekonałem się, że powyższe jest praktyczne w projektach zarządzanych w ten sposób od samego początku. Znacząco poprawiłem zasięg dużych, starszych projektów i warto było to zrobić, ale nigdy nie uważałem za praktyczne wracać i wypełniać każdą lukę pokrycia, ponieważ stary nieprzetestowany kod nie jest wystarczająco dobrze zrozumiany, aby zrobić to poprawnie i szybko.

Jeśli przeprowadzałeś testy jednostkowe przez przyzwoity czas, nie widzę powodu, aby nie zbliżać się do 95% +. Jednak przynajmniej zawsze pracowałem z 80%, nawet jeśli dopiero zaczynasz testować.

Liczba ta powinna zawierać tylko kod napisany w projekcie (z wyłączeniem frameworków, wtyczek itp.), A może nawet wykluczać niektóre klasy złożone w całości z kodu napisanego z wywołań kodu zewnętrznego. Tego rodzaju połączenie powinno być wyśmiewane / karczowane.

Ogólnie rzecz biorąc, z kilku artykułów na temat najlepszych praktyk inżynieryjnych, które przeczytałem, 80% na nowy kod w testach jednostkowych jest punktem, który daje najlepszy zwrot. Powyżej tego CC% daje mniej wad w stosunku do nakładanego wysiłku. Jest to najlepsza praktyka stosowana przez wiele dużych korporacji.

Niestety większość z tych wyników ma charakter wewnętrzny dla firm, więc nie ma literatury publicznej, na którą mógłbym cię wskazać.

Zakres kodu jest świetny, ale tylko o ile korzyści, które z niego czerpiesz, przewyższają koszty / wysiłek związany z jego osiągnięciem.

Od pewnego czasu pracujemy na poziomie 80%, jednak właśnie postanowiliśmy porzucić to i zamiast tego bardziej skupić się na testowaniu. Koncentrując się na złożonej logice biznesowej itp.,

Ta decyzja została podjęta ze względu na coraz więcej czasu spędzonego na pogoni za pokryciem kodu i utrzymywaniu istniejących testów jednostkowych. Czuliśmy, że doszliśmy do punktu, w którym korzyść, którą otrzymaliśmy z zakresu naszego kodu, została uznana za mniejszą niż wysiłek, jaki musieliśmy włożyć w to, aby to osiągnąć.

Krótka odpowiedź: 60–80%

Długa odpowiedź: myślę, że to całkowicie zależy od charakteru twojego projektu. Zazwyczaj zaczynam projekt od testowania jednostkowego każdego praktycznego elementu. Do pierwszego „wydania” projektu powinieneś mieć całkiem niezły procent bazowy na podstawie rodzaju wykonywanego programowania. W tym momencie możesz rozpocząć „wymuszanie” minimalnego pokrycia kodu.

Sprawdź Crap4j . Jest to nieco bardziej wyrafinowane podejście niż proste pokrycie kodu. Łączy pomiary pokrycia kodu z pomiarami złożoności, a następnie pokazuje, który złożony kod nie jest obecnie testowany.

Moja odpowiedź na tę zagadkę to 100% pokrycie linii kodu, który można przetestować, i 0% pokrycie linii kodu, którego nie można przetestować.

Moja obecna praktyka w Pythonie polega na dzieleniu modułów .py na dwa foldery: app1 / i app2 /, a po uruchomieniu testów jednostkowych obliczyć pokrycie tych dwóch folderów i wizualnie sprawdzić ( pewnego dnia muszę zautomatyzować), czy app1 ma 100% pokrycia i app2 ma 0% zasięgu.

Kiedy / jeśli stwierdzę, że te liczby różnią się od standardu, badam i zmieniam projekt kodu, aby zasięg był zgodny ze standardem.

Oznacza to, że mogę zalecić uzyskanie 100% pokrycia linii kodu biblioteki.

Od czasu do czasu sprawdzam także aplikację2 /, aby sprawdzić, czy mogę tam przetestować dowolny kod, a jeśli mogę, mogę przenieść go do aplikacji 1 /

Teraz nie martwię się zbytnio o łączny zasięg, ponieważ może się to bardzo różnić w zależności od wielkości projektu, ale ogólnie widziałem 70% do ponad 90%.

Dzięki pythonowi powinienem być w stanie opracować test dymu, który mógłby automatycznie uruchamiać moją aplikację podczas pomiaru zasięgu i mam nadzieję, że zyskam łączną wartość 100%, łącząc test dymu z najmniejszymi liczbami.

Oglądanie relacji z innej perspektywy: Dobrze napisany kod z wyraźnym przepływem kontroli jest najłatwiejszy do pokrycia, najłatwiejszy do odczytania i zwykle najmniej wadliwy kod. Pisząc kod z myślą o przejrzystości i pokryciu oraz pisząc testy jednostkowe równolegle z kodem, otrzymujesz najlepsze wyniki IMHO.

Moim zdaniem odpowiedź brzmi: „To zależy od tego, ile masz czasu”. Staram się osiągnąć 100%, ale nie robię zamieszania, jeśli nie dostanę go z czasem.

Kiedy piszę testy jednostkowe, noszę inną czapkę niż czapkę, którą noszę podczas opracowywania kodu produkcyjnego. Myślę o tym, co twierdzi testowany kod i jakie sytuacje mogą go złamać.

Zwykle przestrzegam następujących kryteriów lub zasad:

1. Test jednostkowy powinien być formą dokumentacji na temat oczekiwanego zachowania moich kodów, tj. oczekiwane dane wyjściowe przy określonych danych wejściowych i wyjątki, które mogą generować, które klienci mogą chcieć wyłapać (co powinni wiedzieć użytkownicy mojego kodu?)

2. Test jednostkowy powinien mi pomóc odkryć, co się stanie, jeśli jeszcze nie pomyślałem. (Jak uczynić mój kod stabilnym i niezawodnym?)

Jeśli te dwie reguły nie zapewniają 100% zasięgu, niech tak będzie. Ale raz mam czas, analizuję odkryte bloki i linie i stwierdzam, czy nadal istnieją przypadki testowe bez testów jednostkowych, czy też kod należy przefaktoryzować, aby wyeliminować niepotrzebne kody.

To zależy w dużej mierze od twojej aplikacji. Na przykład niektóre aplikacje składają się głównie z kodu GUI, którego nie można przetestować jednostkowo.

Nie sądzę, żeby istniała taka zasada czarno-biała.
Kod powinien zostać przejrzany, ze szczególnym uwzględnieniem najważniejszych szczegółów.
Jeśli jednak nie został przetestowany, ma błąd!

W zależności od krytyczności kodu, gdziekolwiek od 75% -85% jest dobrą regułą. Kod wysyłki należy zdecydowanie przetestować dokładniej niż w domowych instalacjach itp.

Musi to zależeć od tego, na jakim etapie cyklu rozwoju aplikacji jesteś.

Jeśli jesteś w fazie projektowania i masz już zaimplementowany kod, a dopiero teraz zdajesz sobie sprawę, że musisz pomyśleć o pokryciu kodu, musisz sprawdzić swój obecny zasięg (jeśli istnieje), a następnie użyć tej linii bazowej, aby ustawiać kamienie milowe w każdym sprincie (lub średni wzrost w okresie sprintu), co oznacza przyjmowanie długu kodu przy jednoczesnym dostarczaniu wartości dla użytkownika końcowego (przynajmniej z mojego doświadczenia użytkownik końcowy nie obchodzi ani trochę, jeśli zwiększysz test zasięg, jeśli nie widzą nowych funkcji).

W zależności od domeny strzelanie do 95% nie jest nierozsądne, ale muszę powiedzieć, że średnio patrzysz na średni przypadek od 85% do 90%.

Myślę, że najlepszym objawem prawidłowego pokrycia kodu jest to, że ilość konkretnych problemów, które testy jednostkowe pomagają rozwiązać, w rozsądnym stopniu odpowiada rozmiarowi kodu testów jednostkowych, który stworzyłeś.

Myślę, że najważniejsza może być znajomość trendu pokrycia w czasie i zrozumienie przyczyn zmian w tym trendzie. To, czy postrzegasz zmiany w trendach jako dobre czy złe, będzie zależeć od analizy przyczyny.

Celowaliśmy w> 80% do kilku dni wstecz, ale po tym, jak użyliśmy dużo Wygenerowanego kodu, nie dbamy o% wieku, ale raczej zachęcamy recenzenta do sprawdzenia wymaganego zakresu.

Z postu Testivus uważam, że kontekstem odpowiedzi powinien być drugi programista. Powiedziawszy to z praktycznego punktu widzenia, potrzebujemy parametrów / celów, do których należy dążyć. Uważam, że można to „przetestować” w procesie zwinnym, analizując kod, który mamy architekturę, funkcjonalność (historie użytkowników), a następnie wymyślamy liczbę. Na podstawie moich doświadczeń w dziedzinie telekomunikacji powiedziałbym, że 60% to dobra wartość do sprawdzenia.