Pokrycie kodu jest mylącą metryką, jeśli 100% pokrycia jest twoim celem (zamiast 100% testowania wszystkich funkcji).

Możesz dostać 100%, uderzając wszystkie linie raz. Jednak nadal można przegapić testowanie określonej sekwencji (ścieżki logicznej), w której te linie są trafione.
• nie udało Ci się uzyskać 100%, ale nadal przetestowałeś wszystkie 80% / freq używane ścieżki kodu. Posiadanie testów, które sprawdzają każdy' throw ExceptionTypeX ' lub podobny Defensywny strażnik programowania, który włożyłeś jest "nice to have" not a "must have"

Więc zaufaj sobie lub swoim programistom, aby byli dokładni i przejrzeli każdą ścieżkę przez ich kod. Bądź pragmatyczny i nie ścigaj magicznego 100% pokrycia. Jeśli TDD kod należy uzyskać 90% + pokrycie jako bonus. Użyj code-coverage, aby podświetlić fragmenty kodu, które przegapiłeś(nie powinno się zdarzyć, jeśli TDD.. ponieważ piszesz kod tylko po to, aby przejść test. Żaden kod nie może istnieć bez testu partnera. )

Pokrycie kodu jest świetne, ale pokrycie funkcjonalności jest jeszcze lepsze. Nie wierzę w krycie każdego tekstu, który piszę. Ale wierzę w pisanie 100% pokrycie testowe wszystkich funkcjonalności, które chcę zapewnić (nawet dla dodatkowych fajnych funkcji przyszedłem ze sobą i które nie były omawiane podczas spotkań).

Nie obchodzi mnie, czy będę miał kod, który nie jest objęty testami, ale obchodzi mnie, czy zmienię kod i skończę z innym zachowaniem. Dlatego, 100% pokrycie funkcjonalności jest moim jedynym celem.

Przyjęta odpowiedź ma sens-nie ma ani jednego numeru, który będzie miał sens jako standard dla każdego projektu. Są projekty, które po prostu nie potrzebują takiego standardu. Tam, gdzie przyjęta odpowiedź jest krótka, moim zdaniem, chodzi o opisanie, w jaki sposób można podjąć taką decyzję w odniesieniu do danego projektu.

Kiedy ustawić zasięg kodu wymagania

Po pierwsze, dlaczego w ogóle chcesz narzucić taki standard? Ogólnie rzecz biorąc, kiedy chcesz wprowadzić empiryczne zaufanie do swojego procesu. Co mam na myśli mówiąc "empiryczna pewność siebie"? Cóż, prawdziwy cel poprawność . W przypadku większości programów nie możemy tego znać na wszystkich wejściach, więc zadowalamy się stwierdzeniem, że kod jest dobrze przetestowany . Jest to bardziej poznawalne, ale nadal jest subiektywnym standardem: zawsze będzie otwarty na debatę, czy spotkałam go. Debaty te są użyteczne i powinny mieć miejsce, ale również obnażają niepewność.

Pokrycie kodu jest obiektywnym pomiarem: gdy zobaczysz raport pokrycia, nie ma dwuznaczności co do tego, czy standardy zostały spełnione są użyteczne. Czy to dowodzi poprawności? Wcale nie, ale ma on wyraźny związek z tym, jak dobrze przetestowany jest kod, co z kolei jest naszym najlepszym sposobem na zwiększenie zaufania do jego poprawności. Pokrycie kodu jest wymiernym przybliżeniem niezmierzalnego cechy, na których nam zależy.

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

• aby zadowolić zainteresowane strony. W przypadku wielu projektów istnieją różne podmioty zainteresowane jakością oprogramowania, które mogą nie być zaangażowane w codzienny Rozwój oprogramowania (menedżerowie, kierownictwo techniczne itp.) Powiedzenie "napiszemy wszystkie testy, których naprawdę potrzebujemy" nie jest przekonujące: albo muszą zaufać całkowicie, albo zweryfikować z trwającym blisko Nadzór (zakładając, że mają nawet wiedzę techniczną, aby to zrobić.) Zapewnienie wymiernych standardów i Wyjaśnienie, W jaki sposób racjonalnie przybliżają rzeczywiste cele, jest lepsze.
• do normalizacji zachowania zespołu. poza interesariuszami, jeśli pracujesz w zespole, w którym wiele osób pisze kod i testy, jest miejsce na dwuznaczność dla tego, co kwalifikuje się jako "dobrze przetestowane."Czy wszyscy twoi koledzy mają ten sam pomysł, jaki poziom testów jest wystarczająco dobry? Pewnie nie. Jak pogodziłeś się z tym? Znajdź metrykę, na którą wszyscy możecie się zgodzić i zaakceptować ją jako rozsądne przybliżenie. Jest to szczególnie przydatne (ale nie wyłącznie) w dużych zespołach, gdzie leady mogą nie mieć bezpośredniego nadzoru nad młodszymi programistami, na przykład. Sieci zaufania również mają znaczenie, ale bez obiektywnych pomiarów, zachowanie grupowe łatwo staje się niespójne, nawet jeśli wszyscy działają w dobrej wierze.
• aby zachować szczerość. nawet jeśli jesteś jedynym deweloperem i tylko interesariusz dla Twojego projektu, możesz mieć pewne cechy na uwadze dla oprogramowania. Zamiast dokonywać subiektywnych ocen na temat tego, jak dobrze przetestowane jest oprogramowanie (co wymaga pracy), możesz użyć pokrycia kodu jako rozsądnego przybliżenia i pozwolić maszynom zmierzyć go za Ciebie.

Jakich metryk użyć

Pokrycie kodu nie jest pojedynczą metryką; istnieje kilka różnych sposobów pomiaru pokrycia. Który z nich można ustawić standard zależy od tego, co używasz tego standardu, żeby zadowolić.

Użyję dwóch wspólnych wskaźników jako przykładów, kiedy można ich użyć do ustalenia standardów:

• Zakres instrukcji : jaki procent instrukcji został wykonany podczas testowania? Przydatne, aby uzyskać poczucie fizycznego pokrycia Twojego kodu: ile kodu, który napisałem, faktycznie przetestowałem?
  • ten rodzaj pokrycia obsługuje słabszy argument poprawności, ale jest również łatwiejszy do osiągnięcia. Jeśli po prostu używasz pokrycia kodu, aby upewnić się, że rzeczy zostaną przetestowane (a nie jako wskaźnik jakości testu poza tym), a następnie pokrycie oświadczenia jest prawdopodobnie wystarczające.
• Branch coverage : Jeśli istnieje logika rozgałęzień (np. an if), czy obie gałęzie zostały ocenione? To daje lepsze wyczucie zasięgu logicznego Twojego kodu: ile z możliwych ścieżek mój kod może być przetestowany?
  [[20]}ten rodzaj pokrycia jest dużo lepszy wskaźnik, że program został przetestowany w całym zestawie wejść. Jeśli używasz pokrycia kodu jako najlepszego empirycznego przybliżenia pewności poprawności, powinieneś ustawić standardy w oparciu o pokrycie gałęzi lub podobne.

Istnieje wiele innych metryk (pokrycie linii jest podobne do pokrycia instrukcji, ale daje różne wyniki liczbowe dla instrukcji wielowierszowych, na przykład; pokrycie warunkowe i pokrycie ścieżek są podobne do gałęzi pokrycie, ale odzwierciedlają bardziej szczegółowy widok możliwych permutacji wykonania programu, które możesz napotkać.)

Jaki procent wymagać

Na koniec, wracając do pierwotnego pytania: jeśli ustawisz standardy pokrycia kodu, Jaka powinna być ta liczba?

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

Niektóre liczby, które można Wybierz:

• 100%. Możesz to wybrać, ponieważ chcesz mieć pewność, że wszystko jest testowane. Nie daje to żadnego wglądu w jakość testu, ale mówi, że jakiś test jakiejś jakości dotknął każdego stwierdzenia (lub gałęzi itp.) Ponownie, to wraca do stopnia zaufania: jeśli twój zasięg jest poniżej 100%, wiesz niektóre podzbiory Twojego kodu są niesprawdzone.
  • niektórzy mogą twierdzić, że to głupie, i należy tylko przetestować części swojego kod, który jest naprawdę ważny. Argumentowałbym, że należy również zachować tylko te części kodu, które są naprawdę ważne. Pokrycie kodu można poprawić poprzez usunięcie niesprawdzonego kodu.
• 99% (lub 95%, inne liczby w wysokich latach dziewięćdziesiątych.) Odpowiednie w przypadkach, gdy chcesz przekazać poziom zaufania podobny do 100%, ale zostaw sobie trochę marginesu, aby nie martwić się o sporadyczne trudne do przetestowania kącik kodu.
• 80%. Widziałem ten numer w użyciu kilka razy i nie do końca wiem, skąd pochodzi. Myślę, że to może być dziwne przywłaszczenie reguły 80-20; ogólnie rzecz biorąc, celem jest pokazanie, że {47]}większość {48]} Twojego kodu jest testowana. (Tak, 51% również byłoby "większość", ale 80% jest bardziej odzwierciedlające to, co większość ludzi {47]}oznacza {48]} przez większość.) Jest to odpowiednie dla średnich przypadków, w których "dobrze przetestowane" nie jest wysokim priorytetem( nie chcesz marnować wysiłku na testy o niskiej wartości), ale wystarczy priorytet, że nadal chcesz mieć jakiś standard.

Inne uwagi

Powyższe zakłada, że poprawność jest celem. Pokrycie kodu jest tylko informacją; może być istotne dla innych celów. Na przykład, jeśli martwisz się o konserwowalność, prawdopodobnie zależy ci na luźnym sprzężeniu, które może być wykazane przez testowalność, która z kolei może być mierzona (w niektórych modach) przez pokrycie kodu. Tak więc twój standard pokrycia kodu zapewnia empiryczną podstawę do przybliżenia jakości "konserwowalności", jak również.

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

Proces podstawowy to:

1. piszę swoje testy, aby wykonywać wszystkie funkcje i przypadki krawędzi, które mogę wymyślić (Zwykle pracując z dokumentacji).
2. uruchamiam narzędzia do pokrycia kodu
3. sprawdzam wszelkie linie lub ścieżki nie zakryte i wszelkie, które uważam za nieistotne lub nieosiągalne (ze względu na programowanie defensywne) zaznaczam jako nie licząc
4. piszę nowe testy, aby pokryć brakujące linie i poprawić dokumentację, jeśli te przypadki krawędzi nie są wymienione.

W ten sposób, jeśli ja i moi współpracownicy dodamy nowy kod lub zmienimy testy w przyszłości, jest jasna linia, aby powiedzieć nam, czy przegapiliśmy coś ważnego - zasięg spadł poniżej 100%. Zapewnia jednak również elastyczność w radzeniu sobie z różne priorytety testowania.

Chciałbym mieć inny anectode na temat testu, którym chciałbym się podzielić.

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

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

Czy to właściwe 20%? Czy to 20% który reprezentuje kod Twoich użytkowników najbardziej? Możesz dodać jeszcze 50 testy i dodać tylko 2%.

Znowu wraca do mojego Testivus na Pokrycie Kodu Odpowiedź. Ile ryżu należy włożyć do garnka? To zależy.

85% byłoby dobrym punktem wyjścia dla kryteriów checkin.

Prawdopodobnie wybrałbym różne wyższe bary dla kryteriów wysyłki-w zależności od krytyczności testowanych podsystemów / komponentów.

Gdyby to był idealny świat, 100% kodu byłoby objęte testami jednostkowymi. Jednak, ponieważ nie jest to idealny świat, to kwestia tego, na co masz czas. W związku z tym zalecam skupienie się mniej na określonym odsetku, a bardziej na obszarach krytycznych. Jeśli twój kod jest dobrze napisany (lub przynajmniej rozsądny jego faksymile), powinno być kilka kluczowych punktów, w których API są narażone na inny kod.

Skoncentruj swoje wysiłki testowe na tych interfejsach API. Upewnij się, że API są 1) Dobrze udokumentowane i 2) mają napisane przypadki testowe, które pasują do dokumentacji. Jeśli oczekiwane wyniki nie pasują do dokumentów, to masz błąd w kodzie, dokumentacji lub przypadkach testowych. Wszystkie są dobre do sprawdzenia.

Powodzenia!

Jak Na Dobrze zaprojektowany system, w którym testy jednostkowe od początku napędzały rozwój, powiedziałbym, że 85% to dość niska liczba. Małe klasy przeznaczone do testowania nie powinny być trudne do pokrycia lepiej niż to.

Łatwo odrzucić to pytanie czymś takim:

• pokryte linie nie są równe testowanej logice i nie należy zbyt dużo czytać w procentach.

To prawda, ale jest kilka ważnych kwestii dotyczących pokrycia kodu. W moim doświadczenie ta metryka jest rzeczywiście bardzo przydatna, gdy jest używana poprawnie. Powiedziawszy to, nie widziałem wszystkich systemów i jestem pewien, że jest ich mnóstwo, gdzie trudno zobaczyć analizę pokrycia kodu dodającą prawdziwą wartość. Kod może wyglądać tak różnie, a zakres dostępnych frameworków testowych może się różnić.

Ponadto moje rozumowanie dotyczy głównie dość krótkich pętli sprzężenia zwrotnego testu. Dla produktu, który opracowuję Najkrótsza pętla sprzężenia zwrotnego jest dość elastyczna, obejmując wszystko z klasy testy do sygnalizacji między procesami. Testowanie dostarczanego pod-produktu zwykle trwa 5 minut i w przypadku tak krótkiej pętli sprzężenia zwrotnego rzeczywiście możliwe jest użycie wyników testu (a w szczególności metryki pokrycia kodu, której tutaj szukamy) do odrzucenia lub zaakceptowania commitów w repozytorium.

Podczas korzystania z kodu coverage metric nie należy tylko mieć stały (arbitralny) procent, który musi być spełniony. robienie tego nie daje rzeczywistych korzyści z pokrycia kodu analiza moim zdaniem. Zamiast tego zdefiniuj następujące metryki:

Low Water Mark (LWM), najniższa liczba odkrytych linii kiedykolwiek widziana w testowanym systemie
• High Water Mark (HWM), najwyższy procent pokrycia kodu kiedykolwiek widziany dla testowanego systemu

Nowy kod można dodać tylko wtedy, gdy nie przekroczymy LWM i nie przekroczymy HWM. Innymi słowy, zakres kodu jest nie może się zmniejszać , a nowy kod powinien zostać objęty. Zauważ jak ja say should and not must (wyjaśnione poniżej).

Ale czy to nie znaczy, że nie będzie możliwe wyczyszczenie starych sprawdzonych śmieci, do których nie masz już zastosowania? Tak, i dlatego musisz być pragmatyczny w tych sprawach. Są sytuacje, w których zasady muszą być złamane, ale dla typowej codziennej integracji moje doświadczenie to, że te metryki są bardzo przydatne. Dają one następujące dwa implikacje.

• Promowany jest Testowalny kod. Podczas dodawania nowy kod naprawdę musisz się postarać, aby Kod był testowalny, ponieważ będziesz musiał spróbować i pokryć to wszystko swoimi przypadkami testowymi. Testowalny kod to zazwyczaj dobra rzecz.

• Zasięg testowy starszego kodu rośnie z czasem. Kiedy dodajemy nowy kod i nie jesteśmy w stanie pokryć go przypadkiem testowym, można spróbować przykryć trochę starszego kodu, aby ominąć regułę LWM. To czasami konieczne oszustwo przynajmniej daje pozytywny efekt uboczny, że pokrycie legacy code będzie się z czasem zwiększać, co sprawi, że pozornie ścisłe egzekwowanie tych zasad będzie w praktyce praktykowane.

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

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

• Analiza pokrycia kodu jest częścią dynamicznej analizy kodu (w przeciwieństwie do statycznej, tj. Lint). Problemy wykryte podczas dynamicznej analizy kodu (za pomocą narzędzi takich jak rodzina purify, http://www-03.ibm.com/software/products/en/rational-purify-family ) to rzeczy takie jak niezainicjowane odczyty pamięci (UMR), wycieki pamięci itp. te problemy 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 nienormalne przypadki w systemie, ale jeśli chcesz, aby system zawiódł z wdziękiem (tj. zamiast śledzenia błędów może warto włożyć trochę wysiłku w pokrycie nieprawidłowych przypadków w dynamicznej analizie kodu, jak również. Przy odrobinie pecha UMR może doprowadzić do segfaulta lub gorzej.

• Ludzie są dumni z zachowania 100% dla nowego kodu, a ludzie omawiają problemy testowe z podobną pasją jak inne problemy implementacji. Jak można zapisać tę funkcję w bardziej testowalny sposób? Jak byś chciał zatuszować tę nienormalną sprawę?, itd.

I negatyw, dla kompletności.

• w dużym projekcie z wieloma zaangażowanymi programistami, każdy nie będzie testowym geniuszem na pewno. niektórzy ludzie 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. Jest to jeden metryczny, który może dać ci kilka przyjemnych korzyści, jeśli jest stosowany prawidłowo, ale jeśli jest niewłaściwie używany, może w rzeczywistości prowadzić do złych testów. Poza bardzo cennymi efektami ubocznymi wspomnianymi powyżej, pokryta linia pokazuje tylko, że testowany system może dotrzeć do tej linii dla niektórych danych wejściowych i że może wykonać bez zawieszania się lub awarii.

Wiele sklepów nie ceni testów, więc jeśli jesteś powyżej zera, przynajmniej jest jakaś ocena wartości - więc prawdopodobnie niezer nie jest zły, ponieważ wiele z nich jest nadal zerem.

W świecie. Net ludzie często cytują 80% jako powód. Ale mówią to na poziomie rozwiązania. Wolę mierzyć na poziomie projektu: 30% może być w porządku dla projektu interfejsu użytkownika, jeśli masz Selenium itp. lub testy ręczne, 20% dla projektu warstwy danych może być w porządku, ale 95%+ może być całkiem możliwe dla warstwy reguł biznesowych, jeśli nie do końca konieczne. Więc ogólny zasięg może wynosić, powiedzmy, 60%, ale krytyczna logika biznesowa może być znacznie wyższa.

Słyszałem też to: aspire to 100% and you 'll hit 80%; ale aspire to 80% and you' ll hit 40%.

Podsumowując: zastosuj zasadę 80: 20 i pozwól, aby liczba błędów Twojej aplikacji cię poprowadziła.

Używam cobertury i niezależnie od procentu, zalecam aktualizowanie wartości w zadaniu cobertura-check. Co najmniej podnoś totallinerate i totalbranchrate do nieco poniżej bieżącego zasięgu, ale nigdy nie obniżaj tych wartości. Należy również powiązać właściwość Ant build failure z tym zadaniem. Jeśli kompilacja nie powiedzie się z powodu braku pokrycia, wiesz, że ktoś dodał kod, ale nie przetestował go. 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 i nie jestem pewien, co przetestować dalej, używam coverage, aby pomóc mi zdecydować, co przetestować dalej.

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, 50% lub 97%.

Pokrycie kodu to tylko kolejna metryka. Sam w sobie może być bardzo mylący (zobacz www.thoughtworks.com/insights/blog/are-test-coverage-metrics-overrated ). twoim celem nie powinno być zatem osiągnięcie 100% pokrycia kodu, ale raczej upewnienie się, że przetestujesz wszystkie odpowiednie scenariusze aplikacji.

Jeśli robisz 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 jestem nowy w testowaniu.

Ten numer powinien zawierać tylko kod napisany w projekcie (Nie dotyczy frameworków, wtyczek itp.), a może nawet wykluczać pewne klasy składające się w całości z kodu zapisanego wywołaniami zewnętrznego kodu. Ten rodzaj rozmowy powinien być wyśmiewany/stubbed.

Ogólnie rzecz biorąc, z kilku opracowań dotyczących najlepszych praktyk inżynierii, które przeczytałem, 80% dla nowego kodu w testach jednostkowych jest punktem, który daje najlepszy zwrot. Przekroczenie tego CC % daje mniejszą ilość wad w stosunku do wywieranego wysiłku. Jest to najlepsza praktyka stosowana przez wiele dużych korporacji.

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

Pokrycie kodu jest świetne, ale tylko tak długo, jak korzyści, które z niego uzyskasz, przewyższają koszt / wysiłek jego osiągnięcia.

Pracowaliśmy na poziomie 80% od pewnego czasu, jednak właśnie podjęliśmy decyzję, aby porzucić to i skupić się bardziej na naszych testach. Koncentrując się na złożonej logice biznesowej itp.,

Ta decyzja została podjęta ze względu na rosnącą ilość czasu spędzanego na szukaniu zasięgu kodu i utrzymywaniu istniejących testów jednostkowych. Czuliśmy, że mamy doszliśmy do punktu, w którym korzyści, jakie otrzymaliśmy z naszego pokrycia kodu, uznano za mniejsze niż wysiłek, który musieliśmy włożyć, aby go osiągnąć.

Zobacz 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, jaki złożony kod nie jest obecnie testowany.

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

Moją obecną praktyką w Pythonie jest podzielenie modułów. py na dwa foldery: app1 / i app2 / i podczas uruchamiania testów jednostkowych Oblicz pokrycie tych dwóch folderów i wizualnie sprawdź (i musi zautomatyzować to pewnego dnia), że app1 ma 100% pokrycia, a app2 mA 0% pokrycia.

Kiedy / jeśli okaże się, że liczby te różnią się od standardu I zbadaj i zmień wygląd kodu, aby zasięg był zgodny ze standardem.

Oznacza to, że mogę polecić osiągnięcie 100% pokrycia linii kodu biblioteki.

Od czasu do czasu przeglądam app2 / aby sprawdzić, czy mogę przetestować dowolny kod i jeśli mogę przenieść go do app1 /

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

Z python, powinienem być w stanie opracować test dymu, który automatycznie uruchomi moją aplikację podczas pomiaru zasięgu i miejmy nadzieję, że uzyska aggreagate 100% podczas łączenia testu dymu z liczbami unittest.

Przeglądanie zasięgu z innej perspektywy: dobrze napisany kod z wyraźnym przepływem kontroli jest najłatwiejszy do pokrycia, najłatwiejszy do odczytania i zwykle najmniej błędny. Pisząc kod z myślą o jasności i pokryciu oraz pisząc testy jednostkowe równolegle z kodem, otrzymujesz najlepsze wyniki IMHO.

Moim zdaniem odpowiedź brzmi: "to zależy, ile masz czasu". Staram się osiągnąć 100%, ale nie robię zamieszania, jeśli nie dostanę go z czasem, który mam.

Kiedy piszę testy jednostkowe, noszę inny kapelusz w porównaniu do kapelusza, który noszę podczas opracowywania kodu produkcyjnego. Myślę o tym, co testowany kod twierdzi, że robi i jakie są sytuacje, które mogą go złamać.

Zazwyczaj stosuję się do następujących kryteriów lub zasad:

1. Że badanie jednostkowe powinno być formą dokumentacji o tym, jakie jest oczekiwane zachowanie moich kodów, tj. oczekiwane wyjście, biorąc pod uwagę pewne wejście i wyjątki, które mogą rzucić, że klienci mogą chcieć złapać (co użytkownicy mojego kodu powinni wiedzieć?)

2. Że test jednostkowy pomoże mi odkryć Warunki, o których jeszcze nie pomyślałem. (Jak sprawić, by mój kod był stabilny i solidny?)

Jeśli te dwie zasady nie dają 100% pokrycia, niech tak będzie. Ale raz mam czas, analizuję odkryte bloki i linie i ustalam, czy nadal istnieją przypadki testowe bez testów jednostkowych lub czy kod wymaga refakturowania, aby wyeliminować niepotrzebne kody.

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

Poza tym, odpowiedź zależy od metodologii, języka i narzędzi testowania i pokrycia. Podczas robienia TDD w Ruby lub Pythonie nie jest trudno utrzymać 100% pokrycia i warto to zrobić. O wiele łatwiej jest zarządzać 100% pokryciem niż 90% pokrycia. oznacza to, że o wiele łatwiej jest wypełnić luki w zasięgu, gdy się pojawiają (a podczas wykonywania studni TDD luki w zasięgu są rzadkie i zwykle warte twojego czasu) niż zarządzanie listą luk w zasięgu, do których nie dotarłeś i przegapisz regresje zasięgu z powodu ciągłego tła odkrytego kodu.

Odpowiedź zależy również od historii Twojego projektu. Uważam, że powyższe jest praktyczne tylko w projektach zarządzanych w ten sposób od samego początku. Ja znacznie poprawiono zasięg dużych starszych projektów i warto było to zrobić, ale nigdy nie uważałem za praktyczne cofanie się i wypełnianie każdej luki w zasięgu, ponieważ stary, niesprawdzony kod nie jest wystarczająco dobrze zrozumiały, aby zrobić to poprawnie i szybko.

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

Nie wydaje mi się, żeby istniała taka zasada B / W.
Kodeks należy poddać przeglądowi, ze szczególnym uwzględnieniem krytycznych szczegółów.
Jeśli jednak nie został przetestowany, ma błąd!

Krótka odpowiedź: 60-80%

Długa odpowiedź: Myślę, że to całkowicie zależy od charakteru Twojego projektu. Zazwyczaj rozpoczynam projekt od jednostkowego przetestowania każdego praktycznego elementu. Do pierwszego "wydania" projektu powinieneś mieć całkiem dobry procent bazowy w zależności od rodzaju programowania, który wykonujesz. W tym momencie możesz zacząć "egzekwować" minimalny zakres kodu.

W zależności od krytyczności kodu, wszędzie od 75% -85% jest dobrą zasadą. Kod wysyłki należy zdecydowanie przetestować dokładniej niż w narzędziach domowych itp.

To musi zależeć od fazy rozwoju Twojej aplikacji.

Jeśli jesteś na etapie rozwoju przez jakiś czas i masz już dużo zaimplementowanego kodu i dopiero teraz zdajesz sobie sprawę, że musisz pomyśleć o pokryciu kodu, musisz sprawdzić swój bieżący zasięg (jeśli istnieje), a następnie użyć tej linii bazowej, aby ustawić kamienie milowe każdego sprintu( lub średni wzrost w okresie sprintów), co oznacza przejęcie długu kodu przy jednoczesnym kontynuowaniu dostarczania końca wartość użytkownika(przynajmniej z mojego doświadczenia użytkownik końcowy nie obchodzi ani trochę, jeśli zwiększyłeś zasięg testu, jeśli nie widzą nowych funkcji).

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

Myślę, że najlepszym objawem poprawnego pokrycia kodu jest to, że ilość konkretnych problemów, które testy jednostkowe pomagają naprawić, w rozsądny sposób odpowiada wielkości kodu testów jednostkowych, który stworzyłeś.

Myślę, że to, co może mieć największe znaczenie, to wiedza, jaki trend pokrycia jest w czasie i zrozumienie przyczyn zmian w trendzie. To, czy postrzegasz zmiany trendu jako dobre czy złe, zależy od twojej analizy przyczyny.

Kilka dni temu celowaliśmy w >80%, ale po użyciu dużej ilości wygenerowanego kodu, nie dbamy o %wiek, ale raczej zmuszamy recenzenta do podjęcia rozmowy o wymaganym zasięgu.

From The Testivus posting I think the answer context should be the second programmer. Mówiąc to z praktycznego punktu widzenia musimy dążyć do parametru / celów. Uważam, że można to "przetestować" w zwinnym procesie, analizując kod mamy architekturę, funkcjonalność( user stories), a następnie wymyślić numer. Na podstawie mojego doświadczenia w dziedzinie telekomunikacji powiedziałbym, że 60% to dobra wartość do sprawdzenia.