Wszelkie narzędzia / sugestie, jak obalić argument dotyczący jakości pokrycia kodu

11

Teraz wiem, że ludzie mogliby uważać to pytanie za powtarzające się lub zadawane wielokrotnie, w takim przypadku byłbym wdzięczny za link do odpowiednich pytań z odpowiedzią na moje pytanie.

Ostatnio nie zgadzam się z niektórymi ludźmi na temat pokrycia kodu. Mam grupę osób, które chcą, aby nasz zespół zrezygnował z patrzenia na pokrycie kodu w całości na podstawie argumentu, że 100% pokrycie nie oznacza testów dobrej jakości, a zatem kodu dobrej jakości.

Udało mi się odepchnąć, sprzedając argument, że zakres kodu mówi mi o tym, co na pewno nie zostało przetestowane i pomaga nam skoncentrować się na tych obszarach.

(Powyższe zostało omówione w podobny sposób w innych SO pytania, takie jak to - /programming/695811/pitfalls-of-code-coverage )

Argumentem tych ludzi jest - wtedy zespół zareagowałby, szybko tworząc testy niskiej jakości, a tym samym marnując czas, nie dodając żadnej znaczącej jakości.

Rozumiem ich punkt widzenia, ale szukam sposobu na solidniejsze uzasadnienie pokrycia kodu poprzez wprowadzenie bardziej niezawodnych narzędzi / ram, które zajmą się większymi kryteriami pokrycia (Functional, Statement,Decision, Branch, Condition, State, LCSAJ, path, jump path, entry/exit, Loop, Parameter Value etc) .

To, czego szukam, to propozycja połączenia takich narzędzi do pokrycia kodu i praktyk / procesów, które mogłyby im towarzyszyć, co może pomóc mi w odparciu takich argumentów, jednocześnie czując się swobodnie z moją rekomendacją.

Z zadowoleniem przyjmuję również wszelkie towarzyszące komentarze / sugestie oparte na twoim doświadczeniu / wiedzy na temat przeciwdziałania takim argumentom, ponieważ chociaż subiektywne, zakres kodu pomógł mojemu zespołowi być bardziej świadomym jakości kodu i wartości testowania.


Edycja: Aby zmniejszyć zamieszanie związane z moim rozumieniem słabości typowego pokrycia kodu, chcę zauważyć, że nie mam na myśli narzędzi Statement Coverage (lub wierszy kodu wykonywanych) (jest ich mnóstwo). W rzeczywistości jest to dobry artykuł na temat wszystkiego, co jest z nim nie tak: http://www.bullseye.com/statementCoverage.html

Szukałem czegoś więcej niż tylko oświadczenia lub pokrycia linii, wchodząc bardziej w wiele kryteriów i poziomów pokrycia.

Zobacz: http://en.wikipedia.org/wiki/Code_coverage#Coverage_criteria

Chodzi o to, że jeśli narzędzie może powiedzieć nam o naszym zasięgu w oparciu o wiele kryteriów, staje się to rozsądną automatyczną oceną jakości testu. W żadnym wypadku nie próbuję powiedzieć, że zasięg linii jest dobrą oceną. W rzeczywistości taka jest przesłanka mojego pytania.


Edycja:
Ok, może to trochę za bardzo wyświetliłem, ale rozumiesz. Problem polega na ustaleniu procesów / zasad ogólnie we wszystkich zespołach w sposób jednorodny / konsekwentny. Obawa jest ogólna: jak zapewnić jakość testów, jak przydzielić gwarantowany czas bez żadnych środków. Dlatego lubię mierzalną funkcję, która przy wsparciu odpowiednich procesów i odpowiednich narzędzi pozwoliłaby nam poprawić jakość kodu, jednocześnie wiedząc, że nie marnuje się czasu na marnotrawstwo procesów.


EDYCJA: Jak dotąd mam odpowiedzi:

  • Przeglądy kodu powinny obejmować testy w celu zapewnienia jakości testów
  • Pierwsza strategia pomaga uniknąć testów napisanych po fakcie, aby po prostu zwiększyć zasięg
  • Badanie alternatywnych narzędzi, które obejmują kryteria testowe inne niż po prostu Instrukcja / Linia
  • Analiza kodu / liczby znalezionych błędów pomogłaby docenić znaczenie pokrycia i stanowi lepszy przypadek
  • Co najważniejsze, ufaj wkładowi Zespołu, aby postępować właściwie i walczyć o swoje przekonania
  • Bloki objęte / Liczba testów - dyskusyjne, ale mają pewną wartość

Dzięki za niesamowite odpowiedzi do tej pory. Naprawdę to doceniam. Ten wątek jest lepszy niż godziny burzy mózgów z mocami, które są.

MickJ
źródło
4
Nikt nigdzie nie sugeruje spełnienia 100% pokrycia kodu, co jest naprawdę głupcem.
Jimmy Hoffa,
1
Dzięki. I już to wiem i potwierdzam. Ponadto ludzie zazwyczaj kojarzą 100% pokrycia kodu ze 100% pokryciem wyciągiem (lub linią) zwykle. Też nie mogłem się oprzeć - Jimmy, szukali cię wszędzie.
MickJ,
3
„wtedy zespół zareagowałby, tworząc szybko testy niskiej jakości i marnując czas, nie dodając żadnej znaczącej jakości” - świetny zespół!
Piotr Perak,
Ok, może to trochę za bardzo rzuciłem, ale rozumiesz. Problem polega na ustaleniu procesów / zasad ogólnie we wszystkich zespołach w sposób jednorodny / konsekwentny. Obawa jest ogólna: jak zapewnić jakość testów, jak przydzielić gwarantowany czas bez żadnych środków. Dlatego lubię mierzalną funkcję, która przy wsparciu odpowiednich procesów i odpowiednich narzędzi pozwoliłaby nam poprawić jakość kodu, jednocześnie wiedząc, że nie marnuje się czasu na marnotrawstwo procesów.
MickJ,
1
@ JimmyHoffa - Oprogramowanie o znaczeniu krytycznym zazwyczaj wymaga 100% pokrycia kodu.
mouviciel

Odpowiedzi:

9

Z mojego doświadczenia wynika, że ​​pokrycie kodu jest tak przydatne, jak to robisz . Jeśli piszesz dobre testy, które obejmują wszystkie twoje przypadki, zdanie tych testów oznacza, że ​​spełniłeś swoje wymagania. W rzeczywistości jest to dokładnie ten pomysł, którego używa Test Driven Development . Testy piszesz przed kodem, nie wiedząc nic o implementacji (czasami oznacza to, że inny zespół całkowicie pisze testy). Testy te są skonfigurowane w celu sprawdzenia, czy produkt końcowy robi wszystko, co podają w specyfikacji, a NASTĘPNIE piszesz minimalny kod, aby przejść testy.

Problem polega na tym, że jeśli twoje testy nie są wystarczająco mocne, przegapisz przypadkowe przypadki lub nieprzewidziane problemy i napiszesz kod, który tak naprawdę nie spełnia twoich specyfikacji. Jeśli naprawdę chcesz używać testów do weryfikacji kodu, pisanie dobrych testów jest absolutną koniecznością lub naprawdę marnujesz czas.

Chciałem zredagować odpowiedź tutaj, ponieważ zdałem sobie sprawę, że tak naprawdę nie odpowiedziała na twoje pytanie. Zajrzałbym do tego artykułu wiki, aby zobaczyć niektóre deklarowane zalety TDD. To naprawdę sprowadza się do tego, jak Twoja organizacja działa najlepiej, ale TDD jest zdecydowanie czymś używanym w branży.

Ampt
źródło
+1 za sugestię, że najpierw pisanie testów poprawia jakość testów, więc połączenie Test najpierw z Pokryciem kodu jest zdecydowanie pomocne.
MickJ
Tak, zawsze znajdowałem, że jeśli napiszesz testy po opracowaniu kodu, będziesz testować tylko pod kątem tego, co wiesz, że Twój kod przejdzie, lub napiszesz testy w sposób komplementujący implementację, co naprawdę nikomu nie pomaga. Jeśli piszesz testy niezależnie od kodu, skupiasz się na tym, co powinien zrobić kod , a nie na tym, co robi .
Ampt
Dzięki @Ampt. Czy oprócz wzmocnienia procesu za pomocą TDD są jakieś zalecane narzędzia pokrycia kodu, które zajmują się większą liczbą kryteriów pokrycia w bardziej wyczerpujący sposób, pomagając w ten sposób przynajmniej w pewnym stopniu zweryfikować jakość napisanych testów?
MickJ,
Być może rozumiem cię niepoprawnie, ale czy sugerujesz, że różne narzędzia podadzą ci różne zakresy testów? Zawsze miałem doświadczenie, że narzędzia pokrycia obserwują tylko przebieg testów i rejestrują, które wiersze kodu są wykonywane. Narzędzia przełączające nie powinny wtedy mieć wpływu na zasięg, ponieważ liczba wykonanych linii pozostaje taka sama. Byłbym ostrożny wobec narzędzia, które zapewnia większy zasięg dla tego samego testu. To powiedziawszy, nie uważam, że naciśnięcie każdej linii kodu jest dobrą oceną jakości testu, ponieważ jest to dokładność . Dobre testy wynikają z dobrych wymagań.
Ampt
Dzięki. To, o czym mówisz, to Statement Coverage(lub wykonywane wiersze kodu). Szukałem czegoś więcej niż tylko oświadczenia lub pokrycia linii, wchodząc bardziej w multiple coverage criteriapoziomy. Zobacz: en.wikipedia.org/wiki/Code_coverage#Coverage_criteria i en.wikipedia.org/wiki/Linear_Code_Sequence_and_Jump . Chodzi o to, że jeśli narzędzie może powiedzieć nam o naszym zasięgu w oparciu o wiele kryteriów, staje się to rozsądną automatyczną oceną jakości testu. W żadnym wypadku nie próbuję powiedzieć, że zasięg linii jest dobrą oceną. W rzeczywistości taka jest przesłanka mojego pytania.
MickJ,
6

Po pierwsze, ludzie zrobić adwokacką 100% pokrycie:

Większość programistów uważa ... „100% pokrycie wyciągów” za odpowiednie. To dobry początek, ale mało wystarczający. Lepszy standardowy identyfikator zasięgu, aby spełnić tak zwane „100% zasięgu oddziału” ...

Steve McConnell, Kod ukończony , Rozdział 22: Testowanie programistów.

Jak wspomnieliście ty i inni, pokrycie kodu dla samego zasięgu raczej nie osiągnie wiele. Ale jeśli nie możesz wykonać linii kodu, dlaczego jest napisany?

Sugeruję rozwiązanie sporu poprzez zebranie i analizę danych dotyczących własnych projektów.

Do zbierania danych osobiście korzystam z następujących narzędzi:

  • JaCoCo i powiązana wtyczka Eclipse EclEmma do pomiaru pokrycia kodu.
  • Skrypty Ant do automatycznego budowania, testowania i raportowania.
  • Jenkins dla ciągłych kompilacji - każda zmiana kontroli źródła powoduje automatyczną kompilację
  • Wtyczka JaCoCo dla Jenkinsa - rejestruje wskaźniki zasięgu dla każdej kompilacji i wykresy trendów. Umożliwia także definicje progów pokrycia dla jednego projektu, które wpływają na kondycję kompilacji.
  • Bugzilla do śledzenia błędów.

Po wprowadzeniu tego (lub czegoś podobnego) możesz zacząć dokładniej przyjrzeć się swoim danym:

  • czy w źle pokrytych projektach znaleziono więcej błędów?
  • czy w słabo omówionych klasach / metodach znaleziono więcej błędów?
  • itp.

Spodziewałbym się, że twoje dane będą wspierać twoje stanowisko w kwestii pokrycia kodu; to z pewnością moje doświadczenie. Jeśli tak się nie stanie, być może Twoja organizacja odniesie sukces dzięki niższym standardom pokrycia kodu, niż byś chciał. A może twoje testy nie są zbyt dobre. Miejmy nadzieję, że zadanie skupi wysiłki na tworzeniu oprogramowania z mniejszą liczbą defektów, niezależnie od rozwiązania sporu dotyczącego pokrycia kodu.

Nathan Gerhart
źródło
Naprawdę podoba mi się ta odpowiedź. Dziękuję za sugestie dotyczące narzędzi, a co ważniejsze, podoba mi się podejście oparte na danych w celu uzasadnienia pokrycia kodu. Chociaż staram się wierzyć zespołom słowami o jego wartości i i tak nie kwestionowałbym tego. Może to pomóc mi w zbudowaniu solidniejszego uzasadnienia naszych dotychczasowych doświadczeń. Dzięki!
MickJ
4

Argument tych ludzi jest taki: zespół zareagowałby, szybko tworząc testy niskiej jakości, a tym samym marnując czas, nie dodając żadnej znaczącej jakości.

To kwestia zaufania , a nie narzędzi .

Zapytaj ich, dlaczego, jeśli naprawdę wierzą w to oświadczenie, zaufaliby zespołowi, że w ogóle napisają kod?

Steven A. Lowe
źródło
Ponieważ wiedzą, że funkcjonalność kodu jest najważniejsza, dlatego: testowanie, dokumentacja, komentarze, recenzje itp. Można poświęcić bez żadnych bezpośrednich konsekwencji; chociaż się zgadzam, to zły znak.
JeffO,
Ok, może to trochę za bardzo rzuciłem, ale rozumiesz. Problem polega na ustaleniu procesów / zasad ogólnie we wszystkich zespołach w sposób jednorodny / konsekwentny. Obawa jest ogólna: jak zapewnić jakość testów, jak przydzielić gwarantowany czas bez żadnych środków. Dlatego lubię mierzalną funkcję, która przy wsparciu odpowiednich procesów i odpowiednich narzędzi pozwoliłaby nam poprawić jakość kodu, jednocześnie wiedząc, że nie marnuje się czasu na marnotrawstwo procesów.
MickJ,
3

Ok, może to trochę za bardzo rzuciłem, ale rozumiesz. Problem polega na ustaleniu procesów / zasad ogólnie we wszystkich zespołach w sposób jednorodny / konsekwentny.

Myślę, że to jest problem. Deweloperzy nie dbają (i często z doskonałych powodów) o spójne lub globalne zasady i chcą wolności robienia tego, co uważają za słuszne, niż przestrzegania zasad korporacyjnych.

Jest to uzasadnione, chyba że udowodnisz, że globalne procesy i środki mają wartość i pozytywnie wpływają na jakość i szybkość rozwoju.

Zwykła oś czasu:

  1. dev: hej, patrz - dodałem wskaźniki pokrycia kodu do naszego pulpitu nawigacyjnego, prawda?
  2. kierownik: jasne, dodajmy do nich obowiązkowe cele i zgodność
  3. dev: nieważne, pokrycie kodu jest głupie i bezużyteczne, porzućmy to
ptyx
źródło
1
+1 Zbyt wiele razy widziałem w ten sposób, aby się nie zgodzić. W moim przypadku rozmowa przebiega nieco w ten sposób. dev: hej, patrz - dodałem wskaźniki pokrycia kodu do naszego pulpitu nawigacyjnego, prawda? kierownik: jasne, wszystko, co według was poprawia jakość, jest świetne. Szef szefa menedżerów: Myślę, że potrzebujemy jednego procesu między zespołami. Myślę, że pokrycie kodu jest bezcelowe, chyba że możemy zagwarantować wartość z poniesionych kosztów.
MickJ
2

Z mojego doświadczenia wynika, że ​​kilka elementów można połączyć z pokryciem kodu, aby wartość była opłacalna:

Recenzje kodu

Jeśli możesz skierować złe testy z powrotem do programisty, może to pomóc ograniczyć liczbę złych testów, które zapewniają ten bezsensowny zasięg.

Śledzenie błędów

Jeśli masz wiele pokrycia kodu w module, ale nadal otrzymujesz wiele / poważne błędy w tym obszarze, może to wskazywać na problem, w którym programista potrzebuje ulepszenia w swoich testach.

Pragmatyzm

Nikt nie dostanie się w 100% do dobrych testów na nietrywialnym kodzie. Jeśli jako szef zespołu spojrzysz na kod, ale zamiast powiedzieć „musimy dostać się do N%!” identyfikujesz luki i prosisz ludzi o „poprawę zasięgu w module X”, który osiągnie twój cel, nie dając ludziom możliwości grania w system.

Objęte bloki / liczba testów

Większość narzędzi pokrycia kodu zawiera listę bloków objętych i bloków nieobjętych. Połączenie tego z liczbą faktycznych testów pozwala uzyskać metrykę wskazującą, jak „szerokie” są testy, wskazujące złe testy lub sprzężoną konstrukcję. Jest to bardziej przydatne jako delta z jednego sprintu na inny, ale pomysł jest taki sam - połącz zasięg kodu z innymi miernikami, aby uzyskać lepszy wgląd.

Telastyn
źródło
+1 Dobre sugestie, szczególnie podoba mi się opisany blok / liczba testów i recenzji kodu. Chociaż już przeprowadzamy recenzje kodu, warto podkreślić znaczenie dokładniejszego sprawdzenia testów.
MickJ,
2

Oto moje 2 centy.

Istnieje wiele praktyk, na które ostatnio poświęcono wiele uwagi, ponieważ mogą przynieść korzyści w rozwoju oprogramowania. Jednak niektórzy programiści stosują te praktyki na ślepo: są przekonani, że zastosowanie metodologii jest jak wykonanie algorytmu i że po wykonaniu prawidłowych kroków należy uzyskać pożądany rezultat.

Kilka przykładów:

  • Napisz testy jednostkowe ze 100% pokryciem kodu, a uzyskasz lepszą jakość kodu.
  • Stosuj TDD systematycznie, a otrzymasz lepszy projekt.
  • Wykonaj programowanie w parach, a poprawisz jakość kodu i skrócisz czas programowania.

Myślę, że podstawowy problem z powyższymi stwierdzeniami polega na tym, że ludzie nie są komputerami, a pisanie oprogramowania nie przypomina wykonywania algorytmu.

Tak więc powyższe stwierdzenia zawierają pewną prawdę, ale trochę za bardzo upraszczają, np .:

  • Testy jednostkowe wychwytują wiele błędów, a pokrycie kodu wskazuje, które części kodu są testowane, ale testowanie drobiazgów jest bezużyteczne. Na przykład, jeśli kliknięcie przycisku powoduje otwarcie odpowiedniego okna dialogowego, cała logika wysyłania zdarzenia przycisku do komponentu, który otwiera okno dialogowe, może zostać przetestowana za pomocą prostego testu ręcznego (kliknij przycisk): czy opłaca się to jednostce przetestować tę logikę?
  • Chociaż TDD jest dobrym narzędziem do projektowania, nie działa dobrze, jeśli deweloper słabo rozumie problematyczną domenę (patrz np. Ten słynny post ).
  • Programowanie w pary jest skuteczne, jeśli dwóch programistów może współpracować, w przeciwnym razie jest to katastrofa. Doświadczeni programiści mogą również chcieć krótko omówić najważniejsze kwestie, a następnie osobno napisać kod: spędzanie wielu godzin na omawianiu wielu szczegółów, które oboje już znają, może być zarówno nudne, jak i duże straty czasu.

Wracając do pokrycia kodu.

Udało mi się odepchnąć, sprzedając argument, że zakres kodu mówi mi o tym, co na pewno nie zostało przetestowane i pomaga nam skoncentrować się na tych obszarach.

Myślę, że musisz oceniać od przypadku do przypadku, czy warto mieć 100% pokrycia dla określonego modułu.

Czy moduł wykonuje jakieś bardzo ważne i skomplikowane obliczenia? Następnie chciałbym przetestować każdy wiersz kodu, ale także napisać sensowne testy jednostkowe (testy jednostkowe, które mają sens w tej dziedzinie).

Czy moduł wykonuje jakieś ważne, ale proste zadanie, takie jak otwarcie okna pomocy po kliknięciu przycisku? Test ręczny będzie prawdopodobnie bardziej skuteczny.

Argumentem tych ludzi jest - wtedy zespół zareagowałby, szybko tworząc testy niskiej jakości, a tym samym marnując czas, nie dodając żadnej znaczącej jakości.

Moim zdaniem mają rację: nie można egzekwować jakości kodu, wymagając jedynie 100% pokrycia kodu. Dodanie kolejnych narzędzi do obliczania zasięgu i tworzenia statystyk również nie pomoże. Powinieneś raczej omówić, które części kodu są bardziej wrażliwe i powinny być szeroko testowane, a które mniej podatne na błędy (w tym sensie, że błąd można wykryć i naprawić znacznie łatwiej bez użycia testów jednostkowych).

Jeśli przekażesz programistom 100% pokrycia kodu, niektórzy zaczną pisać głupie testy jednostkowe, aby wypełnić swoje obowiązki, zamiast próbować pisać sensowne testy.

w jaki sposób przydzielasz gwarantowany czas bez mierzenia go

Może to iluzja, że ​​możesz zmierzyć ludzką inteligencję i osąd. Jeśli masz kompetentnych kolegów i ufasz ich osądowi, możesz zaakceptować, gdy powiedzą ci „dla tego modułu, zwiększenie zasięgu kodu przyniesie bardzo niewielkie korzyści. Więc nie poświęcajmy na to czasu” lub „dla tego modułu, którego potrzebujemy tyle zasięgu, ile możemy uzyskać, potrzebujemy dodatkowego tygodnia na wdrożenie rozsądnych testów jednostkowych. ”.

Więc (znowu, to moje 2 centy): nie próbuj znaleźć procesu i ustawiać parametrów, takich jak pokrycie kodu, które musi pasować do wszystkich zespołów, dla wszystkich projektów i dla wszystkich modułów. Znalezienie takiego ogólnego procesu jest iluzją i wierzę, że gdy go znajdziesz, będzie on nieoptymalny.

Giorgio
źródło
Wszystko prawda i już się zgadzam. Jeśli zauważysz, że nie obsługuję 100% pokrycia kodu. Chodzi o poprawę jego wartości poprzez zastosowanie technik, narzędzi i procesów bettet. Pomaga również w pełni zrozumieć kryteria pokrycia kodu (większość zakłada, że ​​jest to wiersz / instrukcja). +1 za doskonały post.
MickJ,
2

„zespół zareagowałby, tworząc szybko testy niskiej jakości, a tym samym marnując czas, nie dodając żadnej znaczącej jakości”

To realne ryzyko, nie tylko teoretyczne.

Sam nadmiar kodu jest dysfunkcyjną miarą. Nauczyłem się tej lekcji na własnej skórze. Kiedyś podkreśliłem to bez dostępności wskaźników lub praktyk równoważących. Setki testów, które wychwytują i maskują wyjątki i bez twierdzeń jest brzydką rzeczą.

„propozycja połączenia takich narzędzi do pokrycia kodu oraz praktyk / procesów, aby z nimi skorzystać”

Oprócz wszystkich innych sugestii istnieje jedna technika automatyzacji, która może oceniać jakość testów: testowanie mutacji ( http://en.wikipedia.org/wiki/Mutation_testing ). W przypadku kodu Java działa PIT ( http://pitest.org/ ) i jest to pierwsze narzędzie do testowania mutacji, na które się natknąłem.

Jak zauważasz, brak pokrycia kodu jest łatwo identyfikowalny jako ryzyko jakości oprogramowania. Uczę, że pokrycie kodu jest koniecznym, ale niewystarczającym warunkiem jakości oprogramowania. Musimy przyjąć zrównoważone podejście oparte na karcie wyników do zarządzania jakością oprogramowania.

Xris - ogrodnik Flatbush
źródło
1

Pokrycie kodu z pewnością nie jest dowodem dobrych testów jednostkowych, ponieważ są poprawne.

Ale jeśli nie są w stanie udowodnić, że wszystkie testy jednostkowe są dobre (niezależnie od tego, jaką definicję dobra mogą wymyślić), jest to naprawdę niemowa kwestia.

ozz
źródło
2
Punkty, które nie mówią, są zwykle dyskusyjne . (Podoba mi się tam gra słów - moja pisownia jest często poprawiana).
1

Zawsze uważałem, że pokrycie kodu jest łatwo podatne na efekt Hawthorne . To spowodowało, że zapytałem „dlaczego w ogóle mamy jakieś dane dotyczące oprogramowania?” a odpowiedź zazwyczaj polega na zapewnieniu wysokiego poziomu zrozumienia obecnego stanu projektu, na przykład:

„jak blisko jesteśmy do zrobienia?”

„Jaka jest jakość tego systemu?”

„jak skomplikowane są te moduły?”

Niestety, nigdy nie będzie jednej miary, która wskazywałaby, jak dobry lub zły jest projekt, a każda próba wyprowadzenia tego znaczenia z pojedynczej liczby z konieczności będzie nadmiernie uproszczona. Chociaż dane dotyczą wyłącznie danych, interpretacja ich znaczenia jest zadaniem o wiele bardziej emocjonalnym / psychologicznym i jako taka prawdopodobnie nie może być stosowana ogólnie w zespołach o różnym składzie lub problemach z różnych dziedzin.

W przypadku pokrycia, myślę, że jest często używany jako proxy dla jakości kodu, choć jest to prymitywne. Prawdziwy problem polega na tym, że sprowadza on strasznie skomplikowany temat do jednej liczby całkowitej od 0 do 100, która oczywiście zostanie wykorzystana do prowadzenia potencjalnie niepomocnej pracy w niekończącym się dążeniu do uzyskania 100% zasięgu. Ludzie tacy jak Bob Martin powiedzą, że 100% zasięgu jest jedynym poważnym celem i rozumiem, dlaczego tak jest, ponieważ wszystko inne wydaje się arbitralne.

Oczywiście istnieje wiele sposobów uzyskania zasięgu, które tak naprawdę nie pomagają mi zrozumieć bazy danych - np. Czy warto przetestować toString ()? co z getterami i seterami dla obiektów niezmiennych? Zespół ma tylko tyle wysiłku, aby aplikować w ustalonym czasie i ten czas zawsze wydaje się krótszy niż czas potrzebny na wykonanie doskonałej pracy, więc w przypadku braku idealnego harmonogramu musimy zadowolić się przybliżeniami.

Metodą, którą uznałem za przydatną w dokonywaniu dobrych przybliżeń, jest Crap4J . Teraz jest zepsuty, ale możesz go łatwo przenieść / wdrożyć samodzielnie. Crap4J próbuje powiązać pokrycie kodu ze złożonością cykliczną , sugerując, że kod, który jest bardziej skomplikowany (ifs, whiles, fors itp.), Powinien mieć większy zasięg testu. Dla mnie ten prosty pomysł naprawdę brzmiał prawdziwie. Chcę zrozumieć, gdzie w mojej bazie kodu istnieje ryzyko, a jednym z naprawdę ważnych zagrożeń jest złożoność. Korzystając z tego narzędzia, mogę szybko ocenić, jak ryzykowna jest moja baza kodu. Jeśli jest to skomplikowane, zasięg powinien pójść w górę. Jeśli tak nie jest, nie muszę tracić czasu, próbując objąć każdą linię kodu.

Oczywiście to tylko jedna metryka i YMMV. Musisz poświęcić temu czas, aby zrozumieć, czy ma to dla ciebie sens i czy da Twojemu zespołowi rozsądne poczucie, gdzie jest projekt.

adambender
źródło
Dziękujemy za świetną sugestię użycia cyklicznej złożoności do wybierania kodu zasługującego na pokrycie i łącza Crap4J. Znalazłem też świetny artykuł mówiący o wyciskaniu niesamowitości crap4j w cobertura - schneide.wordpress.com/2010/09/27/…
MickJ
0

Nie powiedziałbym, że powrót i pokrycie istniejącego kodu jest najlepszą drogą do przodu. Twierdziłbym, że sensowne jest pisanie testów obejmujących każdy nowy kod, który napiszesz, lub dowolny kod, który zmienisz.

Po znalezieniu błędów napisz test, który nie powiedzie się z powodu tego błędu, i napraw błąd, aby test zmienił kolor na zielony. Wstaw komentarz testu, dla którego błędu został napisany.

Celem jest posiadanie wystarczającego zaufania do testów, że można wprowadzać zmiany bez obawy o nieoczekiwane skutki uboczne. Sprawdź Efektywna praca ze starszym kodem, aby uzyskać dobre podsumowanie podejść do oswajania nieprzetestowanego kodu.

Michael Brown
źródło