Jak długo powinniśmy spędzać na pisaniu testów jednostkowych pod kątem nowej funkcji lub naprawy błędów?

9

Kiedy muszę zaimplementować nową funkcję lub naprawić błąd, zwykle próbuję odtworzyć sytuację za pomocą testu. Czasami spędzam około 3 godzin wymyślając urządzenia i pisząc test. Rzeczywista implementacja funkcji lub naprawa błędów zajmuje mniej niż 1 godzinę.

Czy ktoś jeszcze spędza co najmniej 3 razy dłużej na napisaniu testu w porównaniu do faktycznej implementacji funkcji lub naprawy błędu? Jaki jest dopuszczalny stosunek czasu spędzonego na pisaniu testu do pisania kodu?

unit-testing 
— Thierry Lam
źródło
2
Pomyśl o tym w ten sposób: czy naprawienie błędu zajęłoby mniej niż godzinę, gdybyś nie miał testu potwierdzającego jego istnienie, a znacznie mniej został naprawiony?
— Michael K
2
Odpowiedz na tytuł pytania: tak długo, jak to zajmie.
— Marcelo
3
Myślę, że niewolnicze posłuszeństwo zasadom TDD bez względu na koszty lub wartość biznesową zawsze stanowi właściwą odpowiedź.
— Jeremy
Jak radzisz sobie z przypadkiem, w którym kierownik chce, abyś wprowadził poprawkę jak najszybciej i nie może czekać na dodatkowy dzień, aby w pełni przetestować wdrożenie?
— Thierry Lam
2
Zwykle wyjaśniam koszty nieprzeprowadzenia testu. Oznacza to, że mogę teraz wysłać poprawkę, ale jeśli nie napiszemy testu, będziemy musieli zrobić wszystko od nowa później. Czasami są w porządku z tym przyszłym kosztem, ale zwykle piszemy testy.
— Christopher Bibbs,

Odpowiedzi:

12

Różni się w zależności od złożoności błędu lub funkcji. Przypominam sobie jeden projekt, który miał 1,5-tygodniowy kosztorys rozwoju ... i 3-miesięczny koszt testów. Zmiana kodu była niewielka, kilka linii tu i tam, ale wpłynęło to na wiele elementów systemu ubezpieczeniowego na wiele sposobów, więc musieliśmy ją bardzo dokładnie przetestować. Innym razem był błąd, który obejmował nawias w niewłaściwym miejscu. Zajęło 2 godziny, aby go znaleźć, 2 sekundy, aby go naprawić, ale około tygodnia przetestowałem dziesiątki scenariuszy, na które zmiana logiki mogła mieć wpływ.

Ogólnie rzecz biorąc, nie martwię się o stosunek czasu poświęcanego na kodowanie do czasu spędzanego na testowaniu, ponieważ po prostu nie ma sposobu na zachowanie dokładności. Uważam, że w niektórych projektach pojawia się stosunek względny projektu, który jest zwykle standardowy (do projektu), ale nawet wtedy może się zmienić później.

Poświęć tyle czasu, ile potrzeba, aby powiedzieć z pewnością, że kod działa poprawnie.

— FrustratedWithFormsDesigner
źródło
6

A może poświęcisz wystarczająco dużo czasu na pisanie testów, dopóki nie pokażesz, że funkcja działa zgodnie z przeznaczeniem lub błąd został poprawnie naprawiony.

Każda sytuacja będzie inna; nie może istnieć jakaś proporcja. Niektóre testy zajmą dziesiątą część czasu niż wdrożenie, inne zajmą setki razy więcej czasu.

— edA-qa mort-ora-y
źródło
To jest prawdziwa odpowiedź.
— DJClayworth,
4

Kiedyś zrobiłem przeżycie po wprowadzeniu testów jednostkowych w projekcie. Wynik: czas poświęcony na pisanie testów ponownie wyniósł około 40%, tak samo jak czas poświęcony na wdrożenie. Ale nie zamierzaliśmy tam uzyskać pełnego zasięgu i był to dobrze ugruntowany projekt o silnej strukturze i konwencjach.

— Michael Borgwardt
źródło
0

Czy liczysz dobrze? Aby dokładnie obliczyć, ile czasu spędzasz na testach, musisz napisać kod bez testu.

Jeśli napisanie testu zajęło Ci naprawdę trzy godziny, a napisanie kodu do jego ukończenia może zająć ponad 5 godzin, możesz naprawić ten sam błąd bez pisania testów.

Tak, bardzo często spędzam znacznie więcej czasu na teście niż sam kod poprawki.

— Edward Strange
źródło
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.