TDD: Co dzieje się przed pierwszym testem jednostkowym?

W większości rozumiem teorię TDD, ale nie mogę wymyślić, jak zacząć. Siadam, aby napisać test jednostkowy dla osobistego projektu i zdaję sobie sprawę. . . Nie mam pojęcia, co testuję. Jakie obiekty, jaka funkcjonalność itp.

Powiedzmy, że chcę napisać aplikację, która pomoże naszej rodzinie zarządzać zadaniami. Oto kilka pytań: Jak przejść od tego pomysłu do pierwszego testu? O ile należy zdecydować, zanim zacznę, a ile mam ustalić po rozpoczęciu pisania testów? Kiedy podejmuję decyzje, np. Czy przechowywać dane w pliku tekstowym czy w bazie danych? Czy powinienem przejść testy akceptacyjne użytkownika, zanim zacznę? Czy powinienem zaprojektować interfejs użytkownika? Czy powinienem mieć specyfikację? (Zdaję sobie sprawę, że przynajmniej niektóre z tych przykładowych pytań są prawdopodobnie w „szarej strefie”).

Czy oprócz pytania tytułowego dotyczącego przejścia do pierwszego testu jednostkowego mógłbyś podać przykład, jak mógłby wyglądać pierwszy test jednostkowy dla projektu takiego jak przykładowy projekt?

Chciałbym zacząć od listy Funkcji i dla każdej Funkcji napisz historie użytkownika, a następnie dla każdego opisu opisz testy.

Pomyśl chwilę o projekcie, a następnie wybierz opis testu i zacznij kodować: refaktor czerwony-zielony-zielony.

Powtarzaj, aż wszystkie testy zakończą się pomyślnie.

Tak, testy akceptacyjne należy uznać za część tego, dołączoną do odpowiedniej historii.

Od samego początku odkryłeś, jak TDD dotyczy projektowania . Zanim napiszesz swój pierwszy test, musisz pomyśleć o tym, jaki będzie twój pierwszy element funkcjonalności i jak wyglądałby Twój program, gdyby ta funkcja działała.

Programiści, którzy nie używają TDD, również muszą o tym pomyśleć - ale mogą „po prostu zanurzyć się” i zacząć pisać coś, cokolwiek. Ale „coś, cokolwiek” nie zawsze jest na drodze do dostarczenia programu, o którym myślałeś, że zamierzasz pisać. Co jest? Jak wyglądałby twój program, gdyby działał? Jakie testy to przejdzie?

Chcę napisać aplikację, która pomoże naszej rodzinie zarządzać zadaniami.

Chłodny. Gdyby ta aplikacja działała, co by to zrobiło? Cóż, Chore można prawdopodobnie przypisać Osobie, prawda?

Person fred = new Person("fred")
Chore mow = new Chore("mow the lawn");
mow.assignTo(fred);
assertEquals(fred, mow.whoIsAssigned());

Jest początek. Nie jest to miejsce, od którego musisz zacząć, niekoniecznie najlepsze miejsce na rozpoczęcie - ale to miejsce. To jest coś, co chcesz, aby Twój kod obsługiwał (chociaż jestem pewien, że możesz wymyślić lepsze nazwy). Zacznij tam, patrz, jak się nie udaje. Niech to minie. Posprzątaj to. Spienić, spłukać, powtórz.

Tak, TDD ma ten problem. Dlatego teraz polecam Behavior Driven Development.

Zacznij ręcznie. Zapisz coś podobnego do historii użytkownika:

• Jako użytkownik
• Po wybraniu opcji Dodaj do koszyka chcę, aby produkt był dodawany w tle w sposób przezroczysty
• Aby móc nieprzerwanie kontynuować zakupy

Jakie funkcje obsługują ten cel (część „Więc to”)?

• Gdy element zostanie dodany do koszyka
  • Koszyk dla użytkownika będzie zawierał nowy przedmiot
  • Całkowita liczba pozycji w koszyku wzrośnie o jeden
  • Użytkownik nie powinien być przekierowywany
  • Opcja sprawdzenia teraz będzie dostępna
• Gdy w koszyku znajdują się dwa przedmioty, a użytkownik decyduje się na wypłatę
  • Użytkownik zostanie przekierowany na stronę kasy
  • Oba elementy będą widoczne

To wszystko, co możesz i powinieneś sprawdzić ręcznie.

Zrób to przez chwilę. Następnie, jak dobry programista, zacznij szukać sposobów automatyzacji zbędnych części. Różni się to w zależności od platformy, ale większość ma przyzwoite ramy.

.Net ma WatiN do automatyzacji strony internetowej lub, jeśli chcesz przetestować API, poleciłbym dodatek Subspec do xUnit lub MSpec (możesz to również zrobić z dowolnym środowiskiem testowym, tylko te ułatwiają nazywanie testów w pewien sposób który wspiera ten styl myślenia).

Ruby ma ogórek do testowania automatyzacji i rspec do testowania API niższego poziomu

JavaScript ma jaśmin i qUnit.

kropka kropka kropka

Jak przejść od tego pomysłu do pierwszego testu? O ile należy zdecydować, zanim zacznę, a ile mam ustalić po rozpoczęciu pisania testów?

Podziel swoją aplikację na małe historie. („Jako użytkownik chcę dwukrotnie kliknąć ikonę i uruchomić program.” Lub „Jako użytkownik chcę otworzyć przeglądarkę i przejść do programu.” Cokolwiek.)

Następnie podziel historię na kilka zadań. (np. Utwórz projekt w Eclipse, skonfiguruj repozytorium kodu) Kiedy przejdziesz do zadania kodowania, napisz swój pierwszy test.

Kiedy podejmuję decyzje, np. Czy przechowywać dane w pliku tekstowym czy w bazie danych?

Jeśli nie masz pewności, wybierz któryś z nich wydaje się prostszy i zrób to. (prawdopodobnie plik tekstowy) Jeśli zauważysz, że popełniłeś błąd, dokonaj refaktoryzacji. Jeśli twoje testy są dobrze skonstruowane, powinieneś być w stanie dokonać zmiany zaplecza i wychwycić niezamierzone skutki uboczne, które się pojawiają.

Dziwię się, że żadna z odpowiedzi nie zawierają wzmianki o rzeczywistej rzeczy , które zrobić tuż przed napisaniem swój pierwszy test, który ma utworzyć listę testową . Lista testów jest oparta na fazach pisania historii i projektowania, o których mowa w innych odpowiedziach, i jest bezpośrednim prekursorem do napisania testu, którego szukasz.

Aby uzyskać więcej informacji na temat TDD, poleciłbym Test Driven Development By Example autorstwa Kent Beck. Ma także screencast TDD, który śledzi rozwój niebanalnej biblioteki w czystym stylu TDD z wyjaśnieniami Kenta na każdym etapie procesu. Myślę, że jest to świetny przykład TDD w praktyce, nawet jeśli (z konieczności) jest wykonywany w zaprojektowanym środowisku.

Przed pierwszym testem jednostkowym zastanawiasz się, co chcesz się wydarzyć, a następnie zastanawiasz się, jak to sprawdzić. Następnie napisz ten test, zobacz, jak się nie powiedzie i zaimplementuj trochę kodu, aby go przejść

Spłucz, powtórz itp.

Dla mnie ważne jest myślenie o tym, jak przetestować to trochę, i to może napędzać Twój projekt.