Czy 100% pokrycie kodu jest marzeniem?

Czy można oczekiwać 100% pokrycia kodu w aplikacjach internetowych typu jquery / backbonejs? Czy uzasadnione jest niepowodzenie sprintu z powodu niespełnienia 100% pokrycia, gdy rzeczywiste pokrycie kodu oscyluje w granicach 92% -95% w javascript / jquery?

Jest równie realistyczny, ponieważ nierealny.

Realistyczne
Jeśli masz zautomatyzowane testy obejmujące całą bazę kodu, naleganie na 100% pokrycia jest uzasadnione.
Zależy to również od tego, jak krytyczny jest projekt. Im bardziej krytyczne, tym bardziej uzasadnione jest oczekiwanie / żądanie pełnego pokrycia kodu.
Łatwiej to zrobić dla mniejszych i średnich projektów.

Nierealne
Zaczynasz z pokryciem 0% ...
Projekt jest monstrualny z wieloma, wieloma ścieżkami błędów, które trudno odtworzyć lub uruchomić.
Kierownictwo nie chce zaangażować / zainwestować, aby upewnić się, że zasięg jest dostępny.

Pracowałem nad gamą projektów, od braku zasięgu po przyzwoite. Nigdy nie projekt ze 100%, ale były chwile, w których żałowałem, że nie mamy zasięgu 100%.
Ostatecznie pytanie brzmi, czy istniejący zasięg spełnia wystarczającą liczbę wymaganych przypadków, aby zespół mógł swobodnie wysyłać produkt.

Nie znamy wpływu niepowodzenia na twój projekt, więc nie możemy powiedzieć, czy 92% lub 95% jest wystarczające, czy też 100% jest naprawdę wymagane. Lub w tym przypadku, 100% w pełni testuje wszystko, czego się spodziewasz.

Kto testuje testy?

Jest w najlepszym razie bardzo naiwny i nierealny nawet w sensie teoretycznym i niepraktyczny w sensie biznesowym.

• Jest to nierealne w przypadku kodu o wysokiej złożoności cyklicznej. Istnieje zbyt wiele zmiennych, aby objąć każdą kombinację.
• Jest to nierealne z kodem, który jest bardzo współbieżny. Kod nie jest deterministyczny, więc nie można uwzględnić wszystkich warunków, które mogą się zdarzyć, ponieważ zachowanie zmienia się przy każdym uruchomieniu testowym.
• Jest to nierealistyczne w sensie biznesowym, naprawdę tylko wypłaca dywidendę za pisanie testów dla kodu, który jest krytycznym kodem ścieżki, czyli kodu, który jest ważny i kodu, który może się często zmieniać.

Testowanie każdej linii kodu nie jest dobrym celem

Pisanie testów jest bardzo drogie, to kod musi być napisany i przetestowany sam, to kod, który musi być udokumentowany w tym, co faktycznie próbuje przetestować, to kod, który musi być utrzymywany za pomocą zmian logiki biznesowej i testy kończą się niepowodzeniem, ponieważ są nieaktualne. Utrzymywanie automatycznych testów i dokumentacji na ich temat może być droższe niż utrzymywanie kodu czasami.

Nie oznacza to, że testy jednostkowe i testy integracyjne nie są użyteczne, ale tylko tam, gdzie mają sens, a poza branżami, które mogą zabijać ludzi, nie ma sensu próbować testować każdej linii kodu w bazie kodu. Poza tym krytycznym zabijaniem wiele osób szybko koduje bazy, nie można obliczyć dodatniego zwrotu z inwestycji, który pociąga za sobą 100% pokrycie kodu.

Problem z zatrzymaniem:

W teorii obliczalności problem zatrzymania polega na określeniu, na podstawie opisu dowolnego programu komputerowego i danych wejściowych, czy program zakończy działanie, czy będzie działał wiecznie.

Alan Turing udowodnił w 1936 r., Że ogólny algorytm do rozwiązania problemu zatrzymania dla wszystkich możliwych par program-wejście nie może istnieć. Kluczową częścią dowodu była matematyczna definicja komputera i programu, który stał się znany jako maszyna Turinga; problem zatrzymania jest nierozstrzygalny w przypadku maszyn Turinga. Jest to jeden z pierwszych przykładów problemu decyzyjnego.

Skoro nie możesz nawet udowodnić, że coś działa w 100%, po co to robić?

Proste i proste, w większości przypadków nie ma to żadnego sensu biznesowego.

W większości przypadków 100% pokrycia kodu oznacza, że ​​„trochę oszukałeś”:

• Złożone, często zmieniające się części systemu (takie jak GUI) zostały przeniesione do deklaratywnych szablonów lub innych DSL.
• Wszystkie zewnętrzne systemy dotykające kodu zostały wyizolowane lub obsługiwane przez biblioteki.
• To samo dotyczy każdej innej zależności, szczególnie wymagającej skutków ubocznych.

Zasadniczo trudne do przetestowania części zostały przetoczone do obszarów, w których niekoniecznie liczą się jako „kod”. Nie zawsze jest to realistyczne, ale pamiętaj, że niezależnie od pomocy w testowaniu, wszystkie te praktyki ułatwiają pracę z bazą kodu.

Imponujący przykład 100% zasięgu oddziałów w świecie rzeczywistym , zobacz Jak testowany jest SQLite .

Zdaję sobie sprawę, że twoje pytanie dotyczy w szczególności javascript, który jest zupełnie innym rodzajem oprogramowania, ale chcę zwrócić uwagę na to, co można zrobić z wystarczającą motywacją.

100% pokrycia kodu dla testów jednostkowych dla wszystkich elementów konkretnej aplikacji jest marzeniem, nawet w przypadku nowych projektów. Chciałbym, żeby tak było, ale czasami nie można po prostu zakodować fragmentu kodu, bez względu na to, jak bardzo starasz się oddzielić zewnętrzne zależności. Załóżmy na przykład, że Twój kod musi wywoływać usługę internetową. Możesz ukryć wywołania usługi internetowej za interfejsem, aby wyśmiewać ten kawałek i przetestować logikę biznesową przed usługą internetową i po niej. Ale faktyczny element, który musi wywołać serwis internetowy, nie może być testowany jednostkowo (w każdym razie bardzo dobrze). Innym przykładem jest połączenie z serwerem TCP. Możesz ukryć kod łączący się z serwerem TCP za interfejsem. Ale kodu, który fizycznie łączy się z serwerem TCP, nie można przetestować jednostkowo, ponieważ jeśli z jakiegoś powodu nie działa, spowodowałoby to niepowodzenie testu jednostkowego. Testy jednostkowe powinny zawsze przejść pomyślnie, bez względu na to, kiedy zostaną wywołane.

Dobrą zasadą jest to, że cała logika biznesowa powinna obejmować 100% pokrycia kodu. Ale elementy, które muszą odwoływać się do komponentów zewnętrznych, powinny mieć możliwie bliskie 100% pokrycie kodu. Jeśli nie możesz dosięgnąć, nie pociłbym się za bardzo.

O wiele ważniejsze, czy testy są prawidłowe? Czy dokładnie odzwierciedlają Twoją firmę i wymagania? Posiadanie pokrycia kodu tylko po to, aby mieć pokrycie kodu nic nie znaczy, jeśli wszystko, co robisz, to niepoprawne testowanie lub testowanie niepoprawnego kodu. Biorąc to pod uwagę, jeśli twoje testy są dobre, posiadanie 92-95% zasięgu jest wyjątkowe.

Powiedziałbym, że jeśli kod nie jest zaprojektowany z konkretnym celem polegającym na umożliwieniu 100% pokrycia testowego, 100% może być nieosiągalne. Jednym z powodów byłoby to, że jeśli kodujesz defensywnie - co powinieneś - czasami powinieneś mieć kod, który obsługuje sytuacje, które na pewno nie powinny się zdarzyć lub nie mogą się wydarzyć, biorąc pod uwagę Twoją wiedzę o systemie. Objęcie takiego kodu testami byłoby z definicji bardzo trudne. Brak takiego kodu może być niebezpieczny - co jeśli się mylisz i taka sytuacja zdarza się raz na 256? Co się stanie, jeśli nastąpi zmiana w niezwiązanym miejscu, co uniemożliwi niemożliwe? Itd. Więc 100% może być raczej trudno dostępne za pomocą „naturalnych” środków - np. Jeśli masz kod, który przydziela pamięć i masz kod, który sprawdza, czy się nie udało, chyba że wykpisz menedżera pamięci (co może nie być łatwe) i napisz test, który zwraca „brak pamięci”, obejmujący ten kod może być trudny. W przypadku aplikacji JS może to być defensywne kodowanie wokół możliwych dziwactw DOM w różnych przeglądarkach, możliwych awarii usług zewnętrznych itp.

Powiedziałbym więc, że należy dążyć do bycia tak blisko 100%, jak to możliwe i mieć dobry powód do delty, ale nie widziałbym, aby nie uzyskać dokładnie 100% jako koniecznej awarii. 95% może być w porządku w przypadku dużego projektu, w zależności od 5%.

Jeśli zaczynasz od nowego projektu i używasz wyłącznie metodyki testowej, całkowicie uzasadnione jest posiadanie 100% pokrycia kodu w tym sensie, że cały kod zostanie wywołany w pewnym momencie, gdy testy mają został stracony. Możliwe jednak, że nie przetestowano bezpośrednio każdej indywidualnej metody lub algorytmu ze względu na widoczność metody, aw niektórych przypadkach niektóre metody nie zostały nawet przetestowane pośrednio.

Przetestowanie 100% kodu jest potencjalnie kosztownym ćwiczeniem, szczególnie jeśli nie zaprojektowałeś systemu tak, abyś mógł osiągnąć ten cel, a jeśli koncentrujesz swoje wysiłki projektowe na testowalności, prawdopodobnie nie poświęcasz wystarczającej uwagi zaprojektować aplikację tak, aby spełniała określone wymagania, szczególnie tam, gdzie projekt jest duży. Przykro mi, ale po prostu nie można tego zrobić w obie strony bez narażenia czegoś na szwank.

Jeśli wprowadzasz testy do istniejącego projektu, w którym testowanie nie było wcześniej utrzymywane lub włączone, nie jest możliwe uzyskanie 100% pokrycia kodu bez kosztów ćwiczeń przewyższających wysiłek. Najlepsze, na co możesz liczyć, to zapewnienie pokrycia testowego najważniejszych sekcji kodu, które są nazywane najczęściej.

Czy uzasadnione jest niepowodzenie sprintu z powodu niespełnienia 100% zasięgu, gdy rzeczywiste pokrycie kodu waha się w granicach 92% -95% w javascript / jquery?

W większości przypadków powiedziałbym, że powinieneś wziąć pod uwagę, że twój sprint „nie powiódł się”, jeśli nie osiągnąłeś swoich celów. W rzeczywistości wolę nie myśleć o sprintach w takich przypadkach, ponieważ musisz uczyć się na sprintach, które nie spełniają oczekiwań, aby dobrze zaplanować przy następnym definiowaniu sprintu. Niezależnie od tego nie sądzę, aby rozsądne było uznanie pokrycia kodu za czynnik względnego sukcesu sprintu. Twoim celem powinno być zrobienie wszystkiego, aby wszystko działało zgodnie ze specyfikacją, a jeśli kodujesz najpierw test, powinieneś być pewien, że twoje testy będą wspierać ten cel. Wszelkie dodatkowe testy, które możesz potrzebować dodać, skutecznie pokrywają cukier, a tym samym dodatkowy wydatek, który może cię powstrzymać w zadowalającym ukończeniu sprintu.

Nie robię tego oczywiście, ale zrobiłem to w dwóch dużych projektach. Jeśli i tak masz już strukturę testów jednostkowych, nie jest to trudne, ale składa się na wiele testów.

Czy napotykasz jakąś szczególną przeszkodę, która uniemożliwia ci dotarcie do ostatnich kilku linii? Jeśli nie, jeśli przejście z 95% do 100% zasięgu jest proste, możesz równie dobrze to zrobić. Skoro tu jesteś i pytasz, zakładam, że coś jest . Co to jest

92% jest w porządku. Czuję, że prawdziwe pytania to:

• Czy 92% jest teraz „nową” normą? Jeśli następny sprint ma 88% testów, czy będzie w porządku? Często jest to początek porzucania pakietów testowych.

• Jak ważne jest, aby oprogramowanie działało i nie zawierało błędów. Masz testy z tych powodów, a nie „ze względu na testowanie”

• Czy jest jakiś plan powrotu i wypełnienia brakujących testów?

• Dlaczego testujesz? Wygląda na to, że skupiono się na% pokrycia linii, a nie na funkcjonalności

Martin Fowler pisze na swoim blogu :I would be suspicious of anything like 100% - it would smell of someone writing tests to make the coverage numbers happy, but not thinking about what they are doing.

Istnieją jednak nawet normy, które wymagają 100% pokrycia na poziomie jednostki. Na przykład jest to jeden z wymagań standardów europejskiej społeczności lotów kosmicznych (ECSS, European Cooperation for Space Standization). Artykuł, do którego odsyłam tutaj , opowiada ciekawą historię projektu, którego celem było osiągnięcie 100% pokrycia testowego w już ukończonym oprogramowaniu. Opiera się na wywiadach z zaangażowanymi inżynierami, którzy opracowali testy jednostkowe.

Niektóre z lekcji to:

• 100% zasięgu jest niezwykłe, ale możliwe do osiągnięcia
• Czasami konieczne jest pokrycie 100%
• 100% pokrycia stwarza nowe ryzyko
• Nie optymalizuj pod kątem 100%
• Opracuj odpowiednią strategię, aby zmaksymalizować zasięg
• 100% pokrycia nie jest wystarczającym warunkiem dobrej jakości

Być może pytanie, czy jest wykonalne i uzasadnione, nie jest najbardziej pomocnym pytaniem. Prawdopodobnie najbardziej praktyczną odpowiedzią jest odpowiedź zaakceptowana. Przeanalizuję to na bardziej filozoficznym poziomie.

Idealny byłby 100% zasięg, ale idealnie nie byłby potrzebny lub byłby znacznie łatwiejszy do osiągnięcia. Wolę zastanawiać się, czy jest to naturalne i ludzkie, niż jest to wykonalne lub uzasadnione.

Dzisiejsze narzędzia są prawie niemożliwe. Bardzo trudno jest napisać kod, który jest całkowicie poprawny i nie zawiera błędów. To po prostu nie jest naturalne. Tak więc, bez żadnej innej oczywistej opcji, sięgamy po techniki takie jak TDD i pokrycie kodu śledzenia. Ale tak długo, jak efekt końcowy jest nienaturalny, nie będziesz miał trudności z nakłonieniem ludzi do konsekwentnego i szczęśliwego działania.

Osiągnięcie 100% pokrycia kodu to nienaturalny czyn. Dla większości ludzi zmuszanie ich do osiągnięcia tego byłoby formą tortur.

Potrzebujemy procesów, narzędzi, języków i kodu mapujących nasze naturalne modele mentalne. Jeśli tego nie zrobimy, nie będzie możliwości przetestowania jakości produktu.

Wystarczy spojrzeć na całe oprogramowanie dostępne obecnie. Większość z nich psuje się dość regularnie. Nie chcemy w to wierzyć. Chcemy wierzyć, że nasza technologia jest magiczna i sprawiać nam radość. Dlatego decydujemy się ignorować, usprawiedliwiać i zapominać większość razy, kiedy nasza technologia się psuje. Ale jeśli dokonamy uczciwej oceny rzeczy, większość dzisiejszego oprogramowania jest dość kiepska.

Oto kilka wysiłków, aby kodowanie było bardziej naturalne:

https://github.com/jcoplien/trygve

https://github.com/still-dreaming-1/PurposefulPhp

Później jest wyjątkowo niekompletny i eksperymentalny. Właściwie jest to projekt, który rozpocząłem, ale uważam, że byłby to ogromny krok naprzód w sztuce programowania, gdybym kiedykolwiek zmusił się do poświęcenia czasu na jego ukończenie. Zasadniczo jest to idea, że ​​jeśli kontrakty wyrażają jedyne aspekty zachowania klas, na których nam zależy, a my już wyrażamy kontrakty jako kod, to dlaczego nie tylko mamy definicje klas i metod wraz z kontraktami. W ten sposób umowy byłyby kodem i nie musielibyśmy wdrażać wszystkich metod. Niech biblioteka wymyśli, jak dotrzymać za nas umów.

Osiągnięcie 100% nowego kodu powinno być bardzo możliwe do osiągnięcia i jeśli ćwiczysz TDD, prawdopodobnie trafisz w to domyślnie, ponieważ bardzo celowo piszesz testy dla każdej linii kodu produkcyjnego.

W przypadku istniejącego starszego kodu, który został napisany bez testów jednostkowych, może to być trudne, ponieważ często starszy kod nie został napisany z myślą o testowaniu jednostkowym i może wymagać dużo refaktoryzacji. Ten poziom refaktoryzacji często nie jest praktyczny, biorąc pod uwagę realia ryzyka i harmonogramu, więc dokonujesz kompromisów.

W moim zespole określam 100% pokrycia kodu i jeśli w przeglądzie kodu widzimy mniej niż to, właściciel techniczny komponentu dyskutuje, dlaczego 100% nie zostało osiągnięte z programistą i musi zgodzić się z uzasadnieniem programisty. Często, jeśli wystąpi problem z trafieniem w 100%, programista porozmawia z właścicielem technicznym przed przeglądem kodu. Odkryliśmy, że kiedy nauczysz się nawyku i nauczysz się technik obejścia kilku typowych problemów z dodawaniem testów do starszego kodu, że trafienie w 100% regularnie nie jest tak trudne, jak początkowo myślisz.

Książka Michaela Feather'a „ Skuteczna praca ze starszym kodem” była dla nas nieoceniona przy opracowywaniu strategii dodawania testów do naszego starszego kodu.

Nie, to nie jest możliwe i nigdy nie będzie. Gdyby to możliwe, cała matematyka popadłaby w skończoność. Jak na przykład przetestowałbyś funkcję, która wzięła dwie 64-bitowe liczby całkowite i pomnożyła je? To zawsze był mój problem z testowaniem, a nie sprawdzaniem poprawności programu. W przypadku niczego poza najbardziej trywialnymi programami testowanie jest zasadniczo bezużyteczne, ponieważ obejmuje tylko niewielką liczbę przypadków. To jak sprawdzenie 1000 liczb i powiedzenie, że udowodniłeś hipotezę Goldbacha.