Nowa nazwa testów jednostkowych [zamknięte]

9

Nigdy nie lubiłem testów jednostkowych. Zawsze myślałem, że to zwiększa ilość pracy, którą muszę wykonać.
Okazuje się, że jest to prawdą tylko w odniesieniu do rzeczywistej liczby wierszy kodu, który piszesz, a ponadto jest to całkowicie równoważone wzrostem liczby wierszy przydatnego kodu, który można napisać w ciągu godziny dzięki testom i rozwojowi opartemu na testach.

Teraz uwielbiam testy jednostkowe, ponieważ pozwalają mi pisać użyteczny kod, który dość często działa za pierwszym razem! (odpukać)

Przekonałem się, że ludzie niechętnie przeprowadzają testy jednostkowe lub rozpoczynają projekt z rozwojem opartym na testach, jeśli znajdują się w ściśle określonych ramach czasowych lub w środowisku, w którym inni tego nie robią, więc nie robią tego. Trochę kulturowa odmowa nawet spróbowania.

Myślę, że jedną z najpotężniejszych rzeczy w testowaniu jednostkowym jest pewność, że daje ci to możliwość refaktoryzacji. Daje także nowo znalezioną nadzieję, że mogę przekazać mój kod komuś innemu do refaktoryzacji / ulepszenia, a jeśli moje testy jednostkowe nadal działają, mogę bez obaw korzystać z nowej wersji biblioteki, którą zmodyfikowali.

To ostatni aspekt testów jednostkowych, który moim zdaniem wymaga nowej nazwy. Test jednostkowy jest bardziej umową na to, co ten kod powinien zrobić teraz iw przyszłości.
Kiedy słyszę testowanie słów, myślę o myszach w klatkach, na których przeprowadzono wiele eksperymentów, aby zobaczyć skuteczność związku. To nie jest testowanie jednostkowe, nie wypróbowujemy innego kodu, aby zobaczyć, które podejście jest najbardziej afektywne, określamy, jakich wyników oczekujemy przy pomocy jakich danych wejściowych. W przykładzie myszy testy jednostkowe przypominają bardziej definicje działania wszechświata w przeciwieństwie do eksperymentów przeprowadzanych na myszach.

Czy jestem na crack lub czy ktokolwiek widzi tę odmowę przeprowadzenia testów i czy uważają, że jest to podobny powód, dla którego nie chcą tego robić?
Jakie są powody, dla których ty / inni nie testujesz?
Jak myślisz, jakie są ich motywacje w testach jednostkowych?

A jako nowa nazwa testów jednostkowych, która może rozwiązać niektóre zastrzeżenia, co powiesz o jContract? (Wiem trochę o Java) :) czy kontraktach jednostkowych?

Będzie
źródło
14
Co jest w imieniu? to, co nazywamy różą Pod jakimkolwiek innym imieniem pachniałoby tak słodko; - Szekspir, Romeo i Julia, ok. 1600
Steven A. Lowe
8
Nie wiem czy jesteś na crack. Nigdy nie próbowałem crack ani bycia tobą.
Tim Post
1
Myślę, że idee przywiązują się do słów głównie z powodu pomysłów i postaw do nich związanych, a nie słów. Pamiętam, że dowiedziałem się, że Towarzystwo Spastyczne zmieniło nazwę na Scope, ponieważ nazwa ta była związana z uprzedzeniami. Pamiętam, ponieważ wyjaśniało to, dlaczego wcześniej tego dnia słyszałem, jak dzieci nazywają się „scopey”. Jeśli chcesz zmienić nastawienie, skup się na nastawieniu, a nie na nazwisku - obsesja na punkcie imienia to tylko marnowanie czasu.
Steve314,
2
Projekt na podstawie umowy: en.wikipedia.org/wiki/Design_by_contract Ma określoną konotację, a testy jednostkowe nie są. Jeśli widzę coś z Kontraktem w nazwie, to (i interfejsy) to, co mój mózg z tym kojarzy.
Berin Loritsch
@ Steve314 Scopey. Lubię to. :) Myślę, że w tym przypadku testowanie słów jest już zdefiniowane, a zatem zmiana nazwy testów jednostkowych na niezdefiniowany termin byłaby lepsza. Kontrakt nie może być taki ze względu na wspomniany „interfejs”. Co powiesz na „szybsze tworzenie lepszych programów” lub CBPF.
Czy

Odpowiedzi:

5

Czy jestem na crack lub czy ktokolwiek widzi tę odmowę przeprowadzenia testów i czy uważają, że jest to podobny powód, dla którego nie chcą tego robić?

Słowo testowanie w testach jednostkowych sprawia, że ​​ludzie myślą, że jest to test integracyjny lub interfejs użytkownika, ponieważ to jedyny rodzaj testów, jakie kiedykolwiek przeprowadzili. To jak wstawianie java do javascript.

Kiedy coś ma złą nazwę i wpływa na myślenie ludzi o tym, nazywa się to błędem ramkowania. Błędy kadrowania bywają powierzchowne - ludzie są mądrzy i potrafią przejrzeć różne złe nazwy, złe metafory.

Jakie są powody, dla których ty / inni nie testujesz?

Zależności, które trudno wyśmiewać / sfałszować /

Jak myślisz, jakie są ich motywacje w testach jednostkowych?

Testowanie jednostkowe ma niewielką liczbę koncepcji i należy wykonać nietrywialną ilość pracy, zanim przestaniemy pisać złe testy jednostkowe i zaczniemy pisać dobre. Gdy ludzie stają się lepsi w wyjaśnianiu, czym jest testowanie jednostkowe, adopcja wzrośnie. Z mojego doświadczenia wynika, że ​​testy jednostkowe mają niemal magiczny wpływ na produktywność i jakość kodu. Ale tak się nie zaczęło. Początkowo używałem ram testów jednostkowych jako wygodnego sposobu pisania testów integracyjnych.

MatthewMartin
źródło
Świetne punkty. Próba wyjaśnienia, dlaczego „przetestować” prostą metodę get, jest trudna, wyjaśnienie, dlaczego dla umowy ważna jest stabilność całej reszty kodu, że metoda get zawsze zwraca to, czego oczekujesz, jest łatwiejszym argumentem
Will
3

Koncepcja zmiany nazwy została już zaproponowana. To się nazywa rozwój napędzany zachowaniem . Faceci, którzy to wymyślili, zauważyli wiele takich samych argumentów plus nienaturalne zdolności testowania czegoś, co jeszcze nie zostało stworzone. Zamiast tego ich koncepcją jest napisanie specyfikacji wykonywalnej (o co tak naprawdę chodzi w TDD).

Zauważyłem tę samą odpowiedź. Zauważyłem również, że wiele osób po prostu nie wie, jak pisać testy jednostkowe. Brakuje im dyscyplin procesów naukowych, a jedynie wykorzystują platformę testów jednostkowych jako sposób na połączenie wszystkiego i uruchomienie debuggera. Krótko mówiąc, tak naprawdę nie poprawiają wykorzystania czasu. Nie potrafię powiedzieć, ile testów jednostkowych widziałem o długości kilkudziesięciu linii (ponad 30 linii), a nie jednej instrukcji potwierdzającej. Kiedy to widzę, wiem, że nadszedł czas, aby pracować z programistą i nauczyć ich, co to jest twierdzenie i jak pisać testy jednostkowe, które faktycznie testują.

Berin Loritsch
źródło
2
Plik wykonywalny prawdopodobnie poprzedza TDD / BDD / Agile / XP. Może być tak stary jak CMMI. Kiedyś współzawodniczyła z UML, kiedy ludzie myśleli, że UML jest językiem do pisania ES.
rwong
BDD, podobnie jak TDD, jest podejściem do testowania, a nie rodzajem testowania (funkcjonalna v integracja v jednostka v akceptacja). Autor pyta konkretnie o „lepszą” nazwę do testów jednostkowych.
ybakos
0

W większości przypadków umowy nazywane są w tym przypadku „interfejsami”. Testy jednostkowe nie gwarantują samych umów, ponieważ możesz je również zmienić, więc nie wiesz, że możesz korzystać z nowej wersji biblioteki tylko dlatego, że biblioteka jest testowana. Musisz przetestować kod, który również korzysta z biblioteki. Nie różni się to od innych testów jednostkowych, więc nie rozumiem, dlaczego potrzebowałoby to nowej nazwy.

Myślę, podobnie jak ty, że większość ludzi niechętnie robi testy, ponieważ uważają, że to więcej pracy i nie ma sensu.

Lennart Regebro
źródło
0

Powiem wam, dlaczego nie lubię TDD: to nie dlatego, że nie widzę w nim wartości, ani nie rozpoznaję zalet pakietu testowego, który mogę uruchomić, aby zweryfikować cały mój kod po każdej modyfikacji.

To dlatego, że go nie potrzebuję. Jestem dość old-schoolowym deweloperem, kiedy byłem chłopcem, nie mieliśmy żadnych fantazyjnych zintegrowanych debuggerów z edytowaniem i kontynuowaniem pisania kodu, a kompilacja mogła zająć dość dużo czasu, więc musieliśmy dostać rzeczy tak, od samego początku. Biorąc pod uwagę takie szkolenie, tak naprawdę nie widzę, że napisanie wielu testów jednostkowych sprawiłoby, że byłbym bardziej produktywny lub mój kod byłby bardziej wolny od błędów.

Testuję swój kod, ale jak zawsze to robiłem, dotyczyło to całości, a nie poszczególnych elementów. Więc może mam „testy jednostkowe”, ale są one bardziej gruboziarniste.

To jest mój powód. Nie widzę potrzeby, aby to zrobić. Kod, który tworzę, jest wystarczająco dobry, a jeśli tak, to dlaczego powinienem zmienić swoje procesy, aby naprawić coś, co nie jest zepsute?

gbjbaanb
źródło
Musisz wtedy napisać bardzo prosty kod. Liczba osiągalnych stanów w większości współczesnych systemów oznacza, że ​​przeprowadzenie kompleksowych testów zajęłoby całe życie wszechświata - testowanie dwóch kawałków z 4 bitami stanu wymaga 16 przypadków do przetestowania każdego lub 32 przypadków testowych łącznie; przekształcony w kompleksowy system daje 8 bitów stanu lub 256 przypadków testowych na pokrycie wszystkich stanów. Osobiście wolałbym wykonać 1/8 pracy.
Pete Kirkham
1
@PeteKirkham następstwem tego jest to, że musisz napisać dużą liczbę testów jednostkowych, a następnie także napisać testy integracyjne, aby upewnić się, że urządzenie nadal ze sobą współpracuje. Miejsca, w których pracowałem i które bardzo lubiły testy jednostkowe, spędzały tyle czasu na ich pisaniu (i utrzymywaniu), że przyćmiewały bazę kodu, a ilość pracy, którą wykonali, była niewielka w porównaniu z tym, co osiągam poza tym środowiskiem. Nic nie jest magiczną kulą, zalecam próbę znalezienia bardziej pragmatycznego podejścia, które zapewni zarówno testowanie pokrycia ważnych bitów, a jednocześnie wytworzenie czegoś.
gbjbaanb