Czy 100% pokrycie kodu jest marzeniem?

28

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?

willz
źródło
7
„Fail sprint” brzmi dziwnie złowieszczo…
Donal Fellows
5
To asymptota.
Robert Harvey
12
nawet jeśli masz pełne pokrycie, niektóre błędy nie zostaną znalezione, więc nie polegaj na tym numerze, aby wszystko naprawić
ratchet maniak
11
Wszystko jest możliwe. Prawdziwe pytanie brzmi, czy wartość 100% pokrycia kodu jest warta kosztu czasu i zasobów.
JohnFx
5
Dlaczego martwisz się tym, skoro podstawowe założenie - że 100% (lub jakakolwiek inna liczba) zautomatyzowanego pokrycia testowego w magiczny sposób poprawi Twój kod - jest marzeniem o fajce?
Mason Wheeler,

Odpowiedzi:

30

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.


źródło
30
... A to, że masz 100% pokrycia kodu, nie oznacza, że ​​masz 100% pokrycia oddziału, więc nawet przy 100% pokryciu kodu możesz bardzo dużo stracić.
Bryan Oakley
3
+1 za wielkość projektu. Podział na mniejsze, nadające się do wielokrotnego użytku i testowane elementy pozwoliły nam na uzyskanie ~ 95% zasięgu. 100% pokrycia nie jest konieczne. Testy integracyjne powinny obejmować luki w testach jednostkowych.
Apoorv Khurasia
5
@BryanOakley ... a także twoje testy mogą być bezcelowe, a nawet niczego nie testować
David_001
5
@BryanOakley I nawet przy 100% zasięgu oddziałów możliwe jest, że pewna kombinacja oddziałów może powodować problem. (na przykład dwie sekwencyjne instrukcje IF mogą być rozgałęzione i oddzielne w oddzielnych testach, ale brakuje testu, który wchodzi w oba . Pełne pokrycie gałęzi , ale brakuje jednej ścieżki wykonania)
Izkata
4
Nawet 100% zasięgu oddziału, w tym wszystkie ścieżki wykonania, nie wystarczy. Być może jakiś błąd występuje tylko wtedy, gdy weźmiesz jakąś kombinację gałęzi i masz jakieś dane zewnętrzne, powiedzmy źle sformułowaną datę. Nie ma możliwości, aby wszystkie przypadki zostały kiedykolwiek uwzględnione. Jednocześnie można mieć pewność siebie przy pokryciu mniejszym niż 100%, ale odpowiednio dobrane przypadki krawędziowe jako dane wejściowe.
Andrea
32

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.


źródło
7
to naprawdę musi być zaakceptowana odpowiedź. 100% pokrycia kodu jest prawie tak źle, jak 0%.
Ryathal
1
„Istnieje zbyt wiele zmiennych, aby uwzględnić każdą kombinację”. Nie ma to nic wspólnego z uzyskaniem 100% pokrycia kodu. Jeśli wiersz kodu był wystarczająco ważny, aby go napisać, i jest wystarczająco ważny, aby pozostać w pobliżu, to jest wystarczająco ważny, aby zostać objętym testem. Jeśli test nie jest objęty testem, jedynym bezpiecznym założeniem jest to, że nie działa. Prawdą jest, że w przypadku niektórych kodów testowanie go nie ma sensu z biznesowego punktu widzenia. To jest ten sam kod, który z biznesowego punktu widzenia nie miał sensu pisać.
still_dreaming_1
2
więc myślisz, że pisanie przypadków testowych obejmujących proste getXXX()/setXXX()konstruktory prostych zadań dla wartościowych obiektów to dobre wykorzystanie czasu i zasobów, przepraszam, że tak nie jest w rzeczywistości i niezwykle naiwna opinia, której brakuje doświadczenia w prawdziwym świecie. Pamiętaj, że kod testowy jest nadal kodem, który należy zachować. Im mniej kodu piszesz, aby rozwiązać problem, tym lepiej w każdym przypadku .
Uhm „Jest to nierealne w przypadku kodu o dużej złożoności cyklicznej. Istnieje zbyt wiele zmiennych, aby pokryć każdą kombinację”. - oczywiście dlatego musisz podzielić taki kod na mniejsze części, które mają małą złożoność cykliczną i dlatego są łatwiejsze do przetestowania. Refaktoryzacja w ten sposób jest niezbędna do testowania - ułatwia testowanie.
Predrag Stojadinović
17

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.

Dan Monego
źródło
Jak przenosi się do oszukiwania DSL?
back2dos
2
@ back2dos - Chociaż możesz testować jednostkowo powiedzmy, wbudowane skrypty Pythona, prawdopodobnie nie testujesz jednostkowo szablonów HTML lub CSS, ani licząc linii w nich w kierunku szacunków zasięgu.
Dan Monego,
12

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ą.

Bryan Oakley
źródło
9

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.

bwalk2895
źródło
1
Testowanie tego, co dzieje się, gdy pojawiają się dziwne kombinacje przypadków błędów i braku odpowiedzi, może być wyjątkowo trudne.
Donal Fellows
Czy zrozumienie tego, co zrobi Twój system po przedstawieniu tych trudnych problemów, nie jest częścią atrakcyjności testów jednostkowych? Jest też trochę zamieszania między testami jednostkowymi a testami integracyjnymi.
Peter Smith,
to się łączy unit testingz integration testingtestowaniem kodu, którego nie napisałeś integration. Stos TCP jest w systemie operacyjnym, nie powinieneś go testować, powinieneś założyć, że jest już przetestowany przez tego, kto go napisał.
4

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%.

StasM
źródło
To, że kod nie powinien być uruchamiany w środowisku produkcyjnym w normalnych okolicznościach, nie oznacza, że ​​nie można go napisać w sposób, który mógłby zostać uruchomiony przez testy. Jak ważne jest prawidłowe działanie tego niezwykłego kodu? Czy jest wystarczająco ważne, aby objąć go testami? Twierdziłbym, że jeśli nie jest wystarczająco ważne, aby objąć go testami, nie jest wystarczająco ważne, aby poradzić sobie z tą sprawą. Kod, który nie wymaga testów, to kod, który nie musi istnieć i powinien zostać usunięty.
still_dreaming_1
2

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.

S.Robins
źródło
„Przykro mi, ale po prostu nie można tego zrobić w obie strony bez narażenia czegoś na szwank”. To nie jest prawda. Zawsze możesz przeskalować funkcje lub zwolnić. Jeśli coś nie jest warte testowania, nie warto pisać. Jeśli wiersz kodu jest na tyle ważny, że można go utrzymać, należy go przetestować. Jeśli testowanie nie jest wystarczająco ważne, nie jest wystarczająco ważne, aby pozostać w pobliżu. Jedynym bezpiecznym założeniem, że wiersz kodu, który nie jest testowany, jest taki, że nie działa.
still_dreaming_1
@ still_dreaming_1, wydaje się, że poparłeś moje oświadczenie i zaprzeczyłeś sobie. Zmniejszenie funkcji lub zmiana terminów to kompromisy, z których każdy może wpłynąć na koszty projektu i oczekiwania interesariuszy. Testowanie starszego kodu, który nie został wcześniej w pełni przetestowany, jest niezwykle trudne, ponieważ musisz zrozumieć nie tylko działający kod, ale także intencje oryginalnego twórcy i pisanie testów, które wychwytują zachowanie dotychczasowego kodu że kod działa całkowicie tak, jak powinien.
S.Robins
Chyba chodzi mi o to, że coś, co zostało skompromitowane, funkcje lub zmiany, które jeszcze nie zostały utworzone, ponieważ programowanie przebiega szybciej, nie jest prawdziwym kompromisem, ponieważ jeśli stracisz zasięg, aby poruszać się szybciej, te funkcje i zmiany mogą należy zakładać, że i tak nie działa poprawnie. Więc jaki był sens wprowadzania tych zmian lub dodawania tych funkcji, jeśli nie ma znaczenia, czy działają poprawnie, czy nie? Jeśli nie ma znaczenia, czy działają one poprawnie, zmiany nie musiały zostać wprowadzone i należy je teraz usunąć z kodu.
still_dreaming_1
Nie do końca już w to wierzę, a przynajmniej zdaję sobie sprawę z praktycznego aspektu prawdy, którą wypowiadasz, szczególnie w starszej bazie kodu, więc jest to tylko wyjaśnienie tego, co starałem się wtedy przedstawić. Właściwie jestem teraz całkowicie skonfliktowany nawet przez cały czas robienia TDD na nowej podstawie kodu, nie mówiąc już o uzyskaniu 100% zasięgu. Z jednej strony każda forma logiki i rozumu mówi mi, że obie te rzeczy powinny być dobre, a jednak w praktyce nie mogę sprawić, by było to praktyczne. Więc coś jest bardzo nie tak ze światem programowania, potrzebujemy nowego paradygmatu.
still_dreaming_1
1

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

mjfgates
źródło
To jedna z najlepszych odpowiedzi tutaj. Pytanie o to, co uniemożliwia łatwe pokrycie linii kodu, jest dobrym pytaniem. Uwzględnienie tych linii zmusi cię do ulepszenia kodu, aby tak się stało, więc będzie to zwycięstwo, zwycięstwo.
still_dreaming_1
0

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

Michael Durrant
źródło
„Jak ważne jest, aby oprogramowanie działało i nie zawierało błędów”? Dobre pytanie. Jaka jest definicja błędu? Coś, co nie działa zgodnie z przeznaczeniem. Jeśli ok, jeśli jakiś kod nie działa poprawnie, nie pisz go. Cały kod ma działać.
still_dreaming_1
0

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
użytkownik6681109
źródło
0

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.

still_dreaming_1
źródło
-2

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.

Richard Wells
źródło
-3

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.

bardzo głupie
źródło
O! Tak więc ktoś jest zdenerwowany, że nie odpowiedziałem na problem na płaszczyźnie jego koncepcji; testowanie to marnotrawstwo… Nie obchodzi mnie, czy jest popularny. To nigdy nie zadziała. Nie może Najmądrzejsi informatycy o tym wiedzieli (Dijkstra, Knuth, Hoare i in.). Sądzę, że jeśli jesteś programistą JavaScript, który huffuje programowanie eXtreme, to nie przejmujesz się tymi błędami. Bla, cokolwiek, kogo to obchodzi… napisz kiepski kod. Odpuść CO ^ 2 podczas testów. - Mam na myśli, kto ma więcej czasu, aby usiąść i pomyśleć? Wyeksportowaliśmy to na komputer.
głupie
3
Pytanie jest oznaczone jako „TDD”. TDD jest bardziej narzędziem do projektowania i narzędziem do rozwiązywania problemów niż narzędziem do testowania, a każdy „test” jest tylko przykładem tego, jak kod zachowuje się w określonym kontekście, aby ludzie mogli przeczytać i zrozumieć, co się dzieje, a następnie bezpiecznie go zmienić . Dobra robota TDD prowadzi do czystszego, łatwiejszego w użyciu kodu, a uruchomienie testów sprawdza, czy dokumentacja jest aktualna. Większość pakietów TDD prawie nigdy nie łapie błędów; nie po to są. Myślę, że jesteś oceniany negatywnie, ponieważ twoja odpowiedź zdradza ten brak zrozumienia i mam nadzieję, że ten komentarz w tym pomoże.
Lunivore,