Eksperymentuję z programowaniem opartym na testach i odkryłem, że często dochodzę do następującej sytuacji:

1. Piszę testy dla niektórych funkcji X. Testy te kończą się niepowodzeniem.
2. Próbując zaimplementować X, widzę, że muszę zaimplementować jakąś funkcję Y w dolnej warstwie mojego kodu. Więc...
3. Piszę testy dla Y. Teraz oba testy dla X i Y kończą się niepowodzeniem.

Kiedyś miałem jednocześnie 4 funkcje na różnych warstwach kodu i traciłem koncentrację na tym, co robię (zbyt wiele testów kończy się niepowodzeniem w tym samym czasie).

Myślę, że mógłbym to rozwiązać, wkładając więcej wysiłku w planowanie moich zadań, jeszcze zanim zacznę pisać testy. Ale w niektórych przypadkach nie wiedziałem, że będę musiał zejść głębiej, ponieważ np. Nie znałem zbyt dobrze API dolnej warstwy.

Co powinienem zrobić w takich przypadkach? Czy TDD ma jakieś zalecenia?

Dobrą rzeczą jest to, że zdajesz sobie sprawę, że testowany kod wymaga pomocy. Zamiast wdrożyć go od razu, utwórz interfejs i użyj próbnych testów, aby upewnić się, że twoje testy tagują poprawny kod. Po przejściu testów możesz przejść do implementacji kodu, na którym się opiera.

Stuby i symulacje można wykorzystać do symulacji funkcjonalności, która nie jest jeszcze modyfikowana / wdrażana. Mogą również pomóc w rozwiązaniu zależności, które powodują tego rodzaju „reakcję łańcuchową”.

Z drugiej strony najlepszym rozwiązaniem może być utrzymanie tylko jednego (nieudanego) testu, który doprowadzi do następnej zmiany.

Inne testy ukierunkowane na kod, który opiera się na nowej funkcjonalności, mogą zostać tymczasowo wyłączone, ponieważ w tym momencie nie są tak naprawdę istotne. w twoim przypadku wyłącz testy X, dopóki nie zaimplementujesz Y itp.

W ten sposób możesz skupić się na następnej zmianie, która jest tym, czego chcesz, tak myślę.

Zatrzymać

Z drugiej strony wygląda na to, że mogą tu występować dwa osobne problemy:

1. zapomniałeś niektórych historii i scenariuszy testowych i nie odkryłeś ich, dopóki nie zacząłeś pracować nad konkretnym scenariuszem testowym i / lub

2. faktycznie przeprowadzasz testy jednostkowe, a nie testy funkcji TDD

W przypadku nr 1 zatrzymaj się , wróć i zaktualizuj historie i przetestuj scenariusze, a następnie zacznij od nowa z innym scenariuszem.

W przypadku nr 2 zatrzymaj się i pamiętaj, że testujesz funkcje, a nie jednostki, więc zastosuj symulacje, aby przeświecać inne interfejsy i / lub zaimplementuj więcej kodu, aby test przeszedł pomyślnie bez dodawania nowych scenariuszy testowych. Zakłada się, że nie brakuje Ci scenariuszy testowych, ale zamiast tego - i to jest naprawdę powszechne - łączenie testów jednostkowych i TDD.

To świetne pytanie i OGROMNA frustracja dla mnie również z TDD. Wydaje mi się, że brakuje TDD w tym scenariuszu, w którym po prostu nie masz pojęcia, jakie komponenty lub funkcje niższego poziomu będą potrzebne, dopóki nie zaczniesz opracowywać.

Osobiście odkryłem, że TDD działa tylko wtedy, gdy dokładnie wiesz, co musisz zrobić i do czego zadzwonić, aby wykonać funkcję. Programiści nie zawsze wiedzą wszystko, zanim zaczniemy, więc znalazłem najlepszy sposób na złagodzenie opisanej przez Ciebie sytuacji:

Prototyp

Kiedy tworzę proste prototypowe aplikacje do eksploracji i odkrywania metod i podejść do problemu technicznego, odkrywam dużo pracy nóg i odsuwam te badania na bok, zanim zacznę. Projektowanie i szacowanie stało się również znacznie łatwiejsze.

Jeśli prototyp musi być tak zaangażowany, aby stał się aplikacją, zachęcam cię, abyś nie robił tego leniwie i nie budował testów jednostkowych dla swojego prototypu po fakcie.

W tym momencie powinieneś wiedzieć więcej o interfejsie API niższego poziomu i być w stanie pomyślnie wyśmiewać interfejs API niższego poziomu w komponentach wyższego poziomu.

To zależy od tego, jakie testy sprawdzają twoje pisanie podczas TDD.

Klasyczny model polega na pisaniu testów jednostkowych i wykorzystaniu makiet lub kodów pośredniczących w celu oddzielenia testu od innych „jednostek” kodu.

Istnieje wiele innych alternatywnych modeli, takich jak ATDD, w których testuje się pełny stos lub prawie pełny test. W tym konkretnym przypadku twoje testy pisania potwierdzają wymagane zachowanie programu, a nie pojedynczą jednostkę kodu, abyś nie pisał innych testów. Dostaniesz narzędzie w obie strony, aby spełnić test. Następnie dodajesz inne testy dla innych funkcji / zachowań.