Jakie są wady pisania kodu przed pisaniem testów jednostkowych?

Zawsze widziałem zalecenie, aby najpierw napisać testy jednostkowe, a następnie zacząć pisać kod. Ale czuję, że pójście w drugą stronę jest dla mnie znacznie wygodniejsze - pisz kod, a następnie testy jednostkowe, ponieważ czuję, że po napisaniu właściwego kodu mamy znacznie większą przejrzystość. Jeśli napiszę kod, a następnie testy, być może będę musiał nieco zmienić kod, aby był testowalny, nawet jeśli dużo się skoncentruję na stworzeniu projektu do przetestowania. Z drugiej strony, jeśli napiszę testy, a następnie kod, testy będą się zmieniać dość często w miarę kształtowania się kodu.

Ponieważ widzę wiele zaleceń, aby rozpocząć pisanie testów, a następnie przejść do kodowania, jakie są wady, jeśli zrobię to inaczej - napisz kod, a następnie testy jednostkowe?

Odpowiedź jest czerwona. Czerwony jest tym, co otrzymujesz z cyklu refrakcji TDD czerwono-zielonego, którego nie możesz uzyskać, w testach. Najpierw napisz test zakończony niepowodzeniem. Zobacz, jak się nie udaje. To twoja czerwona i to ważne. Mówi: Mam ten wymóg i wiem , że mój kod go nie spełnia. Kiedy więc przejdziesz do kroku 2 (zielony), z taką samą pewnością wiesz, że Twój kod spełnia ten wymóg. Wiesz, że zmieniłeś bazę kodu w taki sposób, aby spełnić wymagania.

Wymagania (testy) opracowane po kodzie, oparte na kodzie, pozbawiają cię tego rodzaju pewności, pewności.

Jeśli napiszesz kod, a następnie testy, to zbyt łatwo wpaść w pułapkę pisania testów, aby kod przeszedł, zamiast pisania testów, aby upewnić się, że kod spełnia specyfikację.

To powiedziawszy, zdecydowanie nie jest to jedyny sposób na robienie rzeczy i nie ma „najlepszego” sposobu tworzenia oprogramowania. Jeśli włożysz dużo pracy w opracowanie przypadków testowych, nie wiesz, czy proponowana architektura ma jakieś wady do znacznie później - podczas gdy najpierw opracujesz kod, napotkasz je wcześniej i możesz przeprojektować z mniej zatopionymi wysiłek.

W rzeczywistości ludzie rozłączają się na TDD, chodzi o testowanie, chociaż zapominają o dwóch pozostałych literach w akronimie. Coś, co można przeczytać tutaj: TDD bez T lub TDD nie dotyczy testowania .

Chodzi o to, że nauczyłem się wielu innych rzeczy, które są ściśle powiązane z TDD. Nie ma znaczenia, jeśli najpierw wykonasz test: ważne jest myślenie o projektowaniu oprogramowania .

Aby móc nawet pisać testy jednostkowe „we właściwy sposób”, tzn. Aby były one izolowane, szybkie i zautomatyzowane, miejmy nadzieję, że zauważysz, że trzeba trochę przemyśleć sposób ułożenia kodu w taki sposób, aby kod stał się łatwiejszy testować.

Osobiście nauczyłem się zasad SOLIDNYCH, nie wiedząc, że coś takiego zostało napisane. Wynika to z faktu, że pisanie testów jednostkowych zmusiło mnie do przepisania klas, aby nie były zbyt skomplikowane do testowania. Doprowadziło to do:

• Musiałem przenieść funkcjonalność, która albo nie miała sensu, albo opierała się na prywatnych metodach, na osobne klasy, aby móc je przetestować osobno. (Zasada pojedynczej odpowiedzialności).
• Musiałem uniknąć dużych struktur dziedziczenia i zamiast tego rozszerzyć implementacje o kompozycję (widoczne w zasadzie Open-Closed).
• Musiałem sprytnie podchodzić do dziedziczenia, korzystałem z klas abstrakcyjnych za każdym razem, gdy widziałem wspólny kod, który można było udostępniać, i stosowałem metody pośredniczące (zasada podstawienia Liskowa).
• Musiałem pisać interfejsy i klasy abstrakcyjne, aby móc testować klasy osobno. Co nieumyślnie prowadzi do pisania fałszywych obiektów. (Zasada segregacji interfejsu)
• Ponieważ napisałem wiele interfejsów i klas abstrakcyjnych, zacząłem deklarować zmienne i parametry, aby użyć wspólnego typu (zasada inwersji zależności).

Mimo że cały czas nie przeprowadzam testów, zdarza mi się przestrzegać dobrych zasad OO i praktyk, które zaczynasz stosować, aby ułatwić testowanie. Teraz nie piszę kodu dla samego siebie. Napisałem kod, aby można go było łatwo przetestować lub co ważniejsze; łatwe w utrzymaniu .

Wszystkie pozostałe odpowiedzi są dobre, ale jest jeden punkt, który nie został poruszony. Jeśli najpierw napiszesz test, gwarantuje to, że testy zostaną napisane. Po napisaniu działającego kodu kuszące jest, aby pominąć testy i po prostu zweryfikować je za pomocą interfejsu użytkownika. Jeśli masz dyscyplinę, aby zawsze mieć test zakończony niepowodzeniem przed napisaniem kodu, możesz uniknąć tej pułapki.

Jeśli najpierw napiszesz testy, dajesz kolejną szansę na przemyślenie swojego projektu, zanim ten projekt zostanie „odlany w kamieniu”.

Na przykład możesz pomyśleć, że potrzebujesz metody, która wymaga określonego zestawu parametrów. A jeśli najpierw napiszesz kod, napiszesz go w ten sposób i dostosujesz test do określonych parametrów. Ale jeśli najpierw napiszesz test, możesz pomyśleć „poczekaj chwilę, nie chciałbym używać tego parametru w kodzie głównym, więc może powinienem zmienić interfejs API”.

Ponieważ widzę wiele zaleceń, aby zacząć pisać testy, a następnie przejść do kodowania,

Jest to naprawdę dobry powód.

Jeśli powiesz „rób to, co uważasz za słuszne”, ludzie robią najgłupsze i najbardziej szalone rzeczy.

Jeśli powiesz „najpierw napisz testy”, ludzie mogą przynajmniej postąpić właściwie.

jakie są wady, jeśli zrobię to inaczej - napisz kod, a następnie testy jednostkowe?

Zwykle kiepski test i projekt, który należy przerobić, aby można go było przetestować.

Jest to jednak tylko „zwykle”. Niektóre osoby rozwijają projekty i testy równolegle. Niektóre osoby wprowadzają testowalny kod i piszą testy bez przeróbek.

Zasada „Najpierw test” ma na celu nauczanie i instruowanie ludzi, którzy nie mają pojęcia.

W podobny sposób przed przejściem przez ulicę zawsze mówi się „w obie strony”. Jednak tak naprawdę nie. I to nie ma znaczenia. Mieszkam w kraju z kierownicą po prawej stronie i muszę tylko patrzeć w lewo, kiedy zaczynam przekraczać.

Kiedy odwiedzam kraj z kierownicą po lewej stronie, tylko patrzenie w lewo może mnie zabić.

Zasady są określone bardzo mocno z jakiegoś powodu.

To, co robisz, to twój własny problem.

chodzi o to, żeby najpierw napisać test, żebyś pomyślał

• jak przetestować kod
• interfejs, który kod musi przedstawić, aby był testowalny

jeśli robisz coś prostego, prawdopodobnie nie ma znaczenia, który piszesz jako pierwszy (chociaż dobrze jest pielęgnować nawyk pierwszego testu), ponieważ test będzie prosty, a interfejs będzie oczywisty

ale TDD można skalować do testów akceptacyjnych, nie tylko testów jednostkowych, a wtedy interfejs staje się nietrywialny.

Po pierwsze, jeśli najpierw nie napiszesz testów, to nie wykonujesz Test Driven Development (TDD). Korzyści są liczne i często trudno w to uwierzyć, dopóki nie przećwiczysz go wiele razy. Oto korzyści, które otrzymałem dzięki TDD w porównaniu z tradycyjnym rozwojem:

1. Siatka bezpieczeństwa testów - pozwala na dokonywanie dużych zmian bez obawy, że coś się nie stanie
2. Projekt ekologiczny - projekt, który kończę, jest zwykle inny niż projekt, który zrobiłbym od zera i zawsze był lepszy
3. Produktywność - praca nad małymi celami (zaliczenie tego jednego testu) i sprawienie, by (wszystkie testy zdały) działa dla mnie naprawdę dobrze i motywuje mnie do działania. Dodajcie parę, a moja wydajność osiągnie nowy poziom.

Książki: Beck, K. Test-Driven Development by Przykład

Dobry przykład: http://jamesshore.com/Blog/Lets-Play/

Kiedy piszesz test, skąd wiesz, że wykryje warunek niepowodzenia? Odpowiedź brzmi „przetestuj test”. Jak to zrobić, to najpierw napisać test, zobaczyć, że się nie udaje, i zobaczyć, że przejdzie on pomyślnie, gdy testowana jednostka zostanie pomyślnie zakodowana (cykl czerwony / zielony / refaktor wspomniany w jednej z pozostałych odpowiedzi).

Najpierw napisanie kodu, a potem test pozostawia otwarte pytanie, czy test pokaże uczciwe niepowodzenie.

Pamiętaj, że twoje testy wyrażają specyfikację. Jeśli musisz zmienić swoje testy, gdy kod „kształtuje się”, sugeruje to zmianę specyfikacji. To może, ale nie musi, być dobrą rzeczą. Może to oznaczać, że Twoje zrozumienie problemu nie było początkowo prawidłowe. Z drugiej strony może to oznaczać, że testujesz „jak” jednostka wykonuje swoją pracę, a nie to , co powinna osiągnąć.