Różnica między testowaniem jednostkowym a rozwojem opartym na testach


64

Po przeczytaniu opisów rozumiem, że w testach TDD są wykonywane przed napisaniem funkcji, aw testach jednostkowych - po jej zakończeniu.

Czy to główna różnica, czy te dwa terminy nie mogą nawet zostać porównane jako takie. Być może testy jednostkowe są zintegrowaną częścią TDD.

Odpowiedzi:


104

Testowanie jednostkowe odnosi się do tego , co testujesz , a TDD do kiedy testujesz.

Oba są ortogonalne.

Testowanie jednostkowe oznacza, no cóż, testowanie poszczególnych jednostek zachowania. Indywidualna jednostka zachowania jest najmniejszą możliwą jednostką zachowania, którą można indywidualnie przetestować osobno. (Wiem, że te dwie definicje są okrągłe, ale wydaje się, że sprawdzają się całkiem dobrze w praktyce).

Testy jednostkowe możesz pisać przed napisaniem kodu, po napisaniu kodu lub podczas pisania kodu.

TDD oznacza (znowu, dość oczywiste), że twoje testy napędzają twój rozwój (i twój projekt). Możesz to zrobić za pomocą testów jednostkowych, testów funkcjonalnych i testów akceptacyjnych. Zwykle używasz wszystkich trzech.

Najważniejszą częścią TDD jest środkowy D . Pozwolisz, by testy cię poprowadziły . Testy mówią ci, co robić, co robić, kiedy skończysz. Mówią ci, jaki będzie interfejs API, jaki jest projekt. (Jest to ważne: TDD nie polega przede wszystkim na pisaniu testów. Istnieje wiele projektów, które najpierw piszą testy, ale nie ćwiczą TDD. Pisanie testów jako pierwszy jest po prostu warunkiem koniecznym, aby testy mogły napędzać rozwój.)


1
Świetna odpowiedź. dodałby ... TDD polega na tym, że pozwalasz testom na popchnięcie cię i funkcje, które zwiększają wysiłki na rzecz rozwoju ...
Martin

Nie są jednak ortogonalne. Nie możesz mieć TDD bez testów jednostkowych.
JacquesB,

1
@JacquesB, dlaczego? Nasze testy nie są z definicji tak zwanymi testami jednostkowymi, zbyt mocno zależą od infrastruktury i innych komponentów, ale wciąż mamy wystarczającą obserwowalność, że my - przynajmniej niektórzy z nas - robimy TDD.
AProgrammer

3
@AndrewWillems: TDD oznacza, że ​​testy napędzają rozwój . Testy podpowiadają, że nie decydujesz o wyglądzie projektu. Testy podpowiadają, że nie decydujesz, nad czym dalej pracować. Testy mówią, że nie decydujesz, kiedy skończysz. Jest całkowicie możliwe, aby najpierw napisać testy, a następnie zignorować wszystko, co ci mówią. Na przykład możesz najpierw napisać testy, ale potem pisać kod, nawet jeśli wszystkie testy są zielone. Innymi słowy: najpierw piszesz testy, ale traktujesz je jak testy i nie pozwól im kierować rozwojem.
Jörg W Mittag

1
@ JörgWMittag Być może masz rację w purystyczny sposób patrzenia na to, ale wiesz również, że TDD nie jest czarno-biały. Każde rozsądne użycie TDD nie pozwoliłoby, aby testy całkowicie napędzały rozwój, a testy zdecydowanie nie zawsze decydują o tym, jak wygląda projekt (może testy jednostkowe mogą to częściowo zrobić, ale nie testy na wyższym poziomie abstrakcji). Co z refaktoryzacją? Co jest bardzo ważnym aspektem TDD. Również w prawdziwym świecie nie ma czegoś takiego jak „zignoruj ​​wszystko, co mówi test”. Z definicji, jeśli najpierw piszesz testy, używasz „jakiejś formy TDD”.
NickL

21

Testowanie jednostkowe jest elementem rozwoju opartego na testach

Możesz przeprowadzać testy jednostkowe bez programowania opartego na testach. Nie można jednak tworzyć programowania opartego na testach bez użycia testów jednostkowych.

Kiedy wykonujesz tradycyjne testy jednostkowe , piszesz test po napisaniu kodu.

Podejście programistyczne oparte na testach polega na napisaniu testu jednostkowego przed napisaniem kodu.

Najciekawsze zalety TDD (IMHO) w porównaniu do prostych testów jednostkowych:

  • Kod jest w pełni przetestowanym kodem z góry. To bezbolesne testowanie.
  • Zmusza cię do poprawnego zaprojektowania swoich klas.
  • Zmusza cię to również do głupoty .
  • Cykl Red-Green-Refactor jest absolutnym zabójcą zwlekającym!

Czy celowo pominąłeś w jednostce słowo „jednostka”: „Nie można jednak wykonać programowania opartego na testach bez użycia testów”. ?
ratkok

@ratkok: nie, to nie było celowo. Pozwól mi to naprawić.

Najbardziej podoba mi się ta definicja. Lepiej ułożyć je słowami niż innymi odpowiedziami.
Tek

2
Prawdopodobnie możesz wykonywać TDD za pomocą testów modułowych lub testów systemowych zamiast prawdziwych testów jednostkowych. Nie radziłbym tego, ponieważ tracisz wiele korzyści, jeśli testy trwają zbyt długo, ale nie jest to niemożliwe.
Toby Speight

13

TDD i testy jednostkowe są dwoma bardzo szczegółowymi terminami, które często są niewłaściwie używane.

TDD pisze test, który się nie powiedzie, następnie zapisuje minimalną ilość kodu wymaganą do jego uruchomienia, a następnie refaktoryzuje kod, aby był czysty. Odbywa się to w cyklach, fail -> pass -> refactor, dodając nowy test dla każdego znanego wymagania dla kodu. Niedawno TDD stało się jeszcze bardziej szczegółowe na temat pisania testów jednostkowych w tym cyklu, aby odróżnić je od ATDD (podzbiór BDD), który pisze testy akceptacyjne w podobnym cyklu.

Testowanie jednostkowe polega na testowaniu kodu w małych, izolowanych jednostkach. Częstym nieporozumieniem jest myślenie, że jeśli używasz narzędzia do testowania jednostek, takiego jak xUnit lub Rspec, do uruchamiania testów, które piszesz testy jednostkowe. To niekoniecznie jest prawdą. Narzędzi tych można używać do uruchamiania testów powiedzianych przy użyciu środowiska Selenium - w takim przypadku piszesz testy akceptacyjne przy użyciu programu uruchamiającego testy jednostkowe. Testy jednostkowe są bardzo konkretnymi testami, które koncentrują się na małej logice, odizolowanej od wszystkiego ze względu na szybkość (abyś mógł je często uruchamiać i uzyskać szybką informację zwrotną na temat nowych błędów).


1
Testy JUnit dla samego JUnit są dobrym przykładem: znaczna część z nich to testy funkcjonalne i testy akceptacyjne, a nie testy jednostkowe, nawet jeśli są napisane w JUnit. Ponadto twórca JUnit jest również twórcą TDD, a JUnit został opracowany przy użyciu TDD przy użyciu znacznej liczby testów funkcjonalnych i testów akceptacyjnych. Testy akceptacyjne są integralną częścią TDD.
Jörg W Mittag

6

TDD to podejście polegające na pisaniu przypadków testowych przed opracowaniem, jak powiedziałeś, a następnie programista pisze kod, aby przekazać przypadki testowe. Testowanie jednostkowe to termin używany do opisania wąskiego zakresu testów innych niż testy systemowe, testy integracyjne i testy akceptacyjne.


3

TDD to filozoficzne podejście do pisania kodu: najpierw napisz testy. Testy, które piszesz, są testami jednostkowymi.


1

Sposób, w jaki je rozdzielam, polega na rozważeniu, że TDD mniej polega na testowaniu, a więcej na projektowaniu kodu. Następnie stosuje się testy jednostkowe w celu ustalenia oczekiwań dla kodu końcowego. Kiedy kod końcowy jest zapisywany i przechodzi testy (specyfikacje), masz kod, który został zaprojektowany przy użyciu testów.


1

Wszystkie doskonałe odpowiedzi. Dodałbym tylko, że testy jednostkowe zwykle traktują „jednostkę” jako niewielki komponent, podczas gdy TDD można rozszerzyć o testy integracji i akceptacji.

(Niektóre warianty TDD uznają „jednostkę” za najmniejszy krok po kroku w kierunku pożądanej funkcjonalności ...)


powinni, ale z mojego doświadczenia w rzeczywistości tak nie jest. Firmy / grupy twierdzą, że robią TDD, kiedy wszystko, co robią, to zmuszają programistów do testowania najpierw za pomocą testów jUnit, a następnie wykorzystują fakt, że wszystko zostało już przetestowane podczas opracowywania, aby wyeliminować (lub znacznie zmniejszyć) testy jakości i integracji.
jwenting

1
@jwenting nie obwiniaj metodologii za wady tych, którzy twierdzą, że ją praktykuje. dowolne narzędzie może być niewłaściwie użyte
Steven A. Lowe

1
Nie wiem, ale musisz zdać sobie sprawę, że istnieje duża różnica między tym, czym TDD jest w teorii, a tym, co jest w rzeczywistości. A ponieważ większość ludzi (w tym OP) prawdopodobnie tylko widzi rzeczywistość, należy zwrócić uwagę na różnicę.
jwenting

Biorąc pod uwagę, że TDD dotyczy projektowania - dlaczego miałoby obejmować testy akceptacyjne? jak to „napędza” projekt?
Vitalii Isaenko

@VitaliiIsaenko testy akceptacyjne zapewniają najwyższy poziom zakresu dla projektów
Steven A. Lowe
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.