W TDD, jaka jest zaleta uruchamiania testów przed napisaniem pustej metody?

Jestem praktykującym TDD i myślę, że twój sposób na to jest w porządku. Widząc niepowodzenie testu jest ważną częścią, nie widząc niepowodzenia kompilacji kodu.

Spróbuj jako poprawioną sekwencję:

1) Napisz swój test w ciągu komentarz jakby obiekty docelowe i API już istnieje.

2) Napisz tyle kodu API, aby / align = "left" /

3) odkomentuj swój kod testowy.

4) Uruchom test i zobacz, że się nie powiedzie.

5) napisz wystarczy kod, aby go zdobyć żeby przejść.

6) Uruchom test i zobacz, jak przejdzie

7) przepłukać i powtórzyć...

W ten sposób nadal możesz korzystać z myślenia najpierw przetestuj, a nie najpierw zaimplementuj.

Przepływ pracy w Eclipse z JUnit (w przeciwieństwie do Visual Studio z MSTest) to miejsce, w którym kroki 1-3 mają największy sens. Krok 3 to po prostu użycie funkcji Quick Fix Eclipse (Ctrl-1) do wygenerowania kodu stub na podstawie testu jednostkowego, który właśnie napisałeś.

Dosntexistyet someObject = new dosntexistyet ();
int result = someObject.newMethod("123");
assertEquals( 123, wynik);

Szybka poprawka dla pierwszej linii automatycznie utworzy Klasa DoesntExistYet (pozwalająca najpierw przejść przez kreatora, aby ją dostosować), a następna szybka poprawka utworzy dla ciebie newMethod, odpowiednio ustalając podpis na podstawie tego, jak go używałeś.

Więc z całą tą automatyzacją, która ułatwia sprawę, przechodzisz do innych zalet, o których ludzie wspominali, że możesz określić swoje API przez to, w jaki sposób go używasz.

Myślę, że każdemu brakuje punktu krytycznego. skąd wiesz, że pożądana metoda jeszcze nie istnieje? Napisanie testu jednostkowego, który wywołuje metodę, która nie powinna jeszcze istnieć, a następnie oglądanie jej niepowodzenia, weryfikuje, że twoje założenie jest prawdziwe. W języku skompilowanym nie powinno się go kompilować. W języku nieskompilowanym nieudane wykonanie może być znacznie szybsze niż sprawdzenie API. W większości języków dziedziczenie i polimorfizm może skutkować obecnością metody, która nie została zarejestrowana w Twoim mentalny model API.

W rzadkich przypadkach może okazać się, że metoda rzeczywiście istnieje (i IntelliSense może pomóc wykryć, że również), i może zdawać sobie sprawę, że trzeba zmienić pożądaną sygnaturę metody. A może nawet okaże się, że w ogóle nie musisz pisać tej metody (może napisałeś ją w zeszłym tygodniu, ale zapomniałeś).

Z pewnością możesz pominąć te dwa pierwsze kroki lub nawet całkowicie zrezygnować z TDD, ale te kroki miały swój cel. Niemniej Jednak, Ja zgadzam się z ogólnym przekonaniem, że zawsze możemy skorzystać z dokładniejszego opisu przesłanek stojących za takimi krokami w każdej "najlepszej praktyce".

EDIT: z Justina Standard...

Lub jeśli pracujesz w zespole programistów i nie piszesz kodu osobiście polegasz na tym. Myślę, że jest to dość powszechny scenariusz dla większości deweloperów.

EDIT: z senfo...

Jeśli masz problemy z kontrolowaniem, które metody zostały zaimplementowane w bazie klasy, wygląda na to, że Twoja hierarchia dziedziczenia jest zbyt złożona. I still voted się, bo zgadzam się, że poświęcam więcej czasu na sprawdzenie, czy metoda już nie istnieje, jeśli zacznę od testu jednostkowego.

@ senfo: zbyt duża złożoność hierarchii dziedziczenia może z pewnością wystąpić, ale to inny problem z oczywistym rozwiązaniem. Nawet jeśli istniejący kod jest doskonały, nadal warto zacząć od testu jednostkowego, który próbuje wywołać prawdopodobnie nieistniejąca metoda, aby szybko udowodnić sobie, że nie istnieje. Oczywiście pominięcie tego kroku jest zrozumiałe-mogę do niego wrócić w konkretnej sytuacji, w której mój test jest niewłaściwy (aby sprawdzić w tej konkretnej sytuacji, że nie powołuję się na coś innego niż to, co właśnie napisałem).

Pisanie testów najpierw zmusza do decydowania o interfejsach

To wszystko.

Ale to wystarczy! interfejsy to pole, w którym musisz kodować; ignoruj je i po prostu zacznij kodować, a często musisz przerobić swoją pracę, zanim będziesz mógł jej użyć

EDIT: naprawdę powinienem przeczytać pytanie dokładniej, OP szukał bardziej konkretnej odpowiedzi. Oto ona: pomiń krok 2 w visual studio, stub metody/klasy zamiast tego. Nie ma powodu do pedantyzmu o przestrzeganie tej rozszerzonej receptury, gdy wyraźnie nie jest to konieczne przy użyciu narzędzi.

Widzę, że wiele osób odpowiadających na to pytanie ma tło w Visual Studio. Używałem VS siebie i zmagałem się z tymi samymi problemami, które wskazujesz w pierwszych dwóch krokach TDD.

Jeśli używasz bardziej zaawansowanych IDE edycji kodu, jak to, co masz w Javie (Eclipse, Netbeans, IntelliJ), pierwsze dwa kroki mają więcej sensu. Dostępne tam szybkie poprawki i funkcje generowania kodu sprawiają, że pisanie testu przeciwko nieistniejącej klasie lub metodzie jest najszybszym sposobem na stworzenie tego specific class lub declare that specific method; możesz po prostu nacisnąć przycisk, a brakująca klasa lub metoda zostanie wygenerowana za Ciebie. Pisanie wywołania metody lub instancji obiektu jest szybsze niż tworzenie klasy lub metody, a następnie ich używanie. Po wywołaniu metody, na przykład, jest podane przez nazwę Metody i typy parametrów, jaki powinien być podpis metody, więc jest łatwe dla IDE, aby je utworzyć. To naprawdę wspaniały proces i nie zaprogramowałbym żadnego w drugą stronę. Połącz to z zaletami rzeczywistej pracy z api, zanim ono istnieje, opisany sposób wykonywania TDD ma wiele sensu.

To, co tu twierdzę, jest również prawdą w językach dynamicznych, gdzie tradycyjnie nie dostaniesz żadnych błędów kompilacji w IDE dla brakujących klas lub metod. Test się nie powiedzie, dając Ci czerwony pasek.

Dla użytkowników Visual Studio, jeśli chcesz podzielić się tym doświadczeniem, zainstaluj wtyczkę Resharper dla Visual Studio. To będzie podaj wiele z tych samych funkcji, które są dostępne w Java IDEs.

Widząc, że się zepsuł, upewnisz się, że nie pomyliłeś się w kodzie testowym i od samego początku zbudowałeś test roboczy.

Również próba "użycia" API sprawia, że myślisz o tym z innej perspektywy (użytkownika API ), co jest prawie zawsze korzystne. Ważne jest, aby to zrobić zanim spróbujesz napisać API (które będzie zawsze z perspektywy API designer ). Trudno jest wyjaśnić wartość korzystania z własnych interfejsów API, ale termin branżowy to karma dla psów .

Pamiętaj najpierw, że cykl podstawowy to red-green-refactor. Tak więc niepowodzenie kompilacji kodu nie jest częścią podstawowego cyklu TDD. Powiedziawszy, że, jak zauważyło kilka osób, warto rozważyć API pod kątem konstruowanego testu, i to jest miejsce, w którym Twoje pierwsze dwa kroki zwykle wchodzą w swoje własne. Jeśli piszesz API tak, jak chcesz, aby działało tak, aby twój test był prosty, o wiele bardziej prawdopodobne jest, że będziesz szczęśliwym konsumentem testowanej klasy.

Jeśli chodzi o wsparcie Visual Studio dla TDD, zgadzam się, że intellisense czasami będzie przeszkadzało, ale w rzeczywistości można użyć VS dla TDD, choć nadal jest nieco ograniczone. Jeśli metoda testowa odnosi się do nieistniejącej metody na testowanej klasie, możesz utworzyć dla siebie stub, naciskając Ctrl-K, Ctrl - M.

Niestety to nie działa dla właściwości w VS2008, ale z tego co wiem z notatek dla VS2010 jest wiele ulepszeń w tym obszarze w następnym wersja.

Niebezpieczeństwo polega na tym, że podczas pisania pierwszego testu założysz swoje API. Jedną z sztuczek jest pomyślenie o pierwszym teście - może napisz go na papierze lub przynajmniej na zewnątrz VS-zanim zaczniesz pisać kod. Po zapoznaniu się z metodami, których API będzie potrzebował, możesz przejść do kroku 3, a następnie cofnąć się (w odniesieniu do VS) do kroku 1 i napisać rzeczywisty test.

Przyznaję, że zwykle robię większość tego w głowie i zaczynam od kroku (3).

Myślę, że korzystanie z narzędzia takiego jak Resharper pomoże Ci lepiej poczuć TDD. Dla mnie tak.

Dzieje się tak dlatego, że może automatycznie wygenerować wiele pustych klas/metod, które musisz wypisać podczas ich pisania. Pomaga to nie przerywać przepływu, gdy myślisz o tym, jak powinien działać test i jak powinna działać Klasa/metoda, którą testujesz.

To nie jest Test-Driven Development według książki . Na "w 2008 roku firma Beck ogłosiła, że w 2009 roku firma Beck ogłosiła, że ma już ponad 20 lat.]}

• szybko Dodaj test
• Uruchom wszystkie testy i zobacz NOWY fail
• make a little change
• Uruchom testy i zobacz je wszystkie pomyślnie
• Refaktor do usuwania duplikacji

Jeśli O mnie chodzi "see a red squiggle" = = kompilator się nie powiódł. Pamiętaj, że oryginalne manifesty testu jednostkowego/TDD zostały napisane bez IDE w umyśle. Dobre IDE były wtedy bardzo rzadkie w świecie Javy i jak zauważyli inni, języki dynamiczne nadal nie potrafią określić, że metoda nie istnieje w czasie kompilacji, kropka.

Jeśli używasz kombinacji język / IDE, która natychmiast wyświetla błędy kompilacji, to liczy się to jako nieudany cykl kompilacji.

Zgadzam się z innymi respondentami, myślę, że to tylko ludzie, którzy są naiwni, próbując zrobić "dobrą rzecz" bez zastanowienia. Słyszeli gdzieś, że powinieneś napisać swoje testy zanim napiszesz jakikolwiek kod, i robią to dosłownie i próbują skompilować z jakiegoś powodu.

Jest to związane z ta odpowiedź na inne pytanie , użyj najpierw głowy! To najlepsza praktyka.