TDD z niejasnymi wymaganiami

Question

Wiem, że TDD bardzo pomaga i podoba mi się ta metoda rozwoju, kiedy najpierw tworzysz test, a następnie wdrażasz funkcjonalność. Jest to bardzo jasne i poprawne.

Ale z powodu jakiegoś smaku moich projektów często zdarza się, że gdy zaczynam rozwijać jakiś moduł, niewiele wiem o tym, czego chcę i jak będzie wyglądał koniec. Wymagania pojawiają się w miarę rozwoju, mogą występować 2 lub 3 iteracje, gdy usuwam całość lub część starego kodu i piszę nowe.

Widzę dwa problemy: 1. Chcę zobaczyć wynik tak szybko jak to możliwe, aby zrozumieć, czy moje pomysły są dobre czy złe. Testy jednostkowe spowalniają ten proces. Tak więc często zdarza się, że piszę testy jednostkowe po zakończeniu kodu, co jest znane jako zły wzorzec. 2. Jeśli najpierw napiszę testy, muszę przepisać nie tylko kod dwa razy lub więcej razy, ale także testy. To zajmuje dużo czasu.

Czy ktoś mógłby mi powiedzieć, w jaki sposób można zastosować TDD w takiej sytuacji?

Z góry dziękuję!

Answer 1

Chcę zobaczyć wynik tak szybko jak to możliwe, aby zrozumieć, czy moje pomysły są dobre czy złe. Testy jednostkowe spowalniają ten proces.

Nie zgadzam się. Testy jednostkowe i TDD często przyśpieszają uzyskiwanie wyników, ponieważ zmuszają cię do skupienia się na wynikach, zamiast implementować mnóstwo kodu, którego możesz nigdy nie potrzebować. Pozwala także na uruchamianie różnych części kodu podczas pisania, dzięki czemu można ciągle zobaczyć, jakie są wyniki, a nie czekać, aż cały program zostanie ukończony.

Answer 2

TDD pomaga wyrazić intencje swojego kodu. Oznacza to, że pisząc test, musisz powiedzieć, czego oczekujesz od swojego kodu. To, w jaki sposób twoje oczekiwania są spełnione, jest wtedy drugorzędne (to jest realizacja). Zadaj sobie pytanie: "Co jest ważniejsze, implementacja lub jaka jest zapewniona funkcjonalność?" Jeśli jest to implementacja, nie musisz pisać testów. Jeśli jest to zapewniona funkcjonalność, najpierw pomoże Ci napisanie testów.

Kolejną cenną rzeczą jest to, że dzięki TDD nie można wdrożyć funkcjonalności, która nie będzie potrzebna. Piszesz tylko kod, który musi spełnić twoje intencje. Nazywa się to również YAGNI (nie będziesz tego potrzebować).

Answer 3

Uważam, że TDD działa szczególnie dobrze w tego rodzaju sytuacji; w rzeczywistości powiedziałbym, że posiadanie niejasnych i/lub zmieniających się wymagań jest w rzeczywistości bardzo powszechne.

Uważam, że najlepszym sposobem wykorzystania TDD jest upewnienie się, że kod wykonuje to, czego się od niego oczekuje. Kiedy piszesz jakiś kod, powinieneś wiedzieć, co chcesz zrobić, czy wymagania są jasne, czy nie. Siłą TDD jest to, że jeśli jest zmiana wymagań, możesz po prostu zmienić jeden lub więcej testów jednostek, aby odzwierciedlić zmienione wymagania, a następnie zaktualizować kod, upewniając się, że nie łamiesz innych (niezmienionych) funkcjonalność.

Myślę, że jedną rzeczą, która wyprawia wielu ludzi z TDD jest założenie, że testy muszą być napisane wcześniej. Myślę, że bardziej efektywne jest używanie reguły, że nigdy nie piszesz kodu implementacyjnego, podczas gdy wszystkie twoje testy mijają; to po prostu zapewnia, że ​​cały kod jest objęty, zapewniając jednocześnie, że sprawdzasz, czy cały kod robi to, co chcesz, bez obawy o zapisanie wszystkich testów z góry.

Answer 4

W tej wczesnej fazie prototypowej uważam, że wystarczy napisać testowalny kod. Oznacza to, że kiedy piszesz swój kod, pomyśl o tym, jak umożliwić testowanie, ale na razie skup się na samym kodzie, a nie na testach.

Powinieneś mieć testy na miejscu, kiedy coś popełnisz.

Answer 5

Oto blog, który okazał się skuteczny w wyjaśnianiu zastosowania TDD w bardzo iteracyjnej skali procesu projektowego: http://blog.extracheese.org/2009/11/how_i_started_tdd.html.

Answer 6

Korzystanie z programu TDD może w rzeczywistości przyspieszyć pisanie kodu - brak możliwości napisania testu dla określonego scenariusza może oznaczać problem z wymaganiami.
Gdy jesteś w TDD, powinieneś szybciej znaleźć te problematyczne miejsca zamiast po napisaniu 80% kodu.

Istnieje kilka rzeczy, które możesz zrobić, aby testy bardziej odporne na zmiany:

1. Należy starać się ponownie wykorzystać kod wewnątrz swoich badań w postaci fabrycznie metod, które tworzy test obiektów wraz z metodami sprawdzania, które sprawdzają wynik testu. Ten sposób, jeśli niektóre główne zmiany zmienią występuje w kodzie, masz mniej kod, aby zmienić w teście.

2. Zastosowanie kontenerów IoC zamiast przechodzenia argumentów głównych klas - ponownie, jeśli podpis metody zmian nie trzeba zmieniać wszystkich testów.

3. Spraw, aby Twoje testy jednostkowe były krótkie i izolowane - każdy test powinien sprawdzać tylko jeden aspekt kodu i wykorzystywać szyderstwo/izolację, aby test był niezależny od zewnętrznych obiektów.

4. Test i zapis kodu tylko dla wymaganej funkcji (YAGNI). Spróbuj zadać sobie pytanie, jaką wartość otrzyma mój klient od kodu, który piszę. Nie twórz zbyt skomplikowanej architektury, zamiast tego twórz potrzebną funkcjonalność, kawałek po kawałku, a jednocześnie zmieniaj kod.

Answer 7

Nie ma uciec od niego - jeśli pomiar jak długo to trwa do kodu po prostu jak długo to trwa, aby napisać klas, itp, wtedy będzie ona trwać dłużej z TDD. Jeśli masz doświadczenie, dodasz około 15%, jeśli jesteś nowy, to zajmie co najmniej 60% więcej, jeśli nie więcej.

ALE, ogólnie będziesz szybszy. Czemu?

• pisząc test pierwszy jesteś określający co chcesz i dostarcza tylko to i nic więcej - stąd oszczędność czasu pisząc niewykorzystany kod
• bez testów, można by pomyśleć, że wyniki są tak oczywiste, że to, co zrobione jest poprawne - kiedy nie jest. Testy pokazują, że to, co zrobiłeś, jest poprawne.
• dostaniesz szybciej zwrotne od zautomatyzowanych testów niż wykonując ręczne testowanie
• z ręcznym testowania czasu potrzebnego do testowania wszystko jak aplikacja rośnie gwałtownie rośnie - co oznacza, że ​​będziesz przestać robić to
• z manualnych testów jest to łatwe do popełnienia błędów i "zobaczenia" czegoś, co mija, kiedy nie jest, jest to szczególnie ważne, jeśli ciągle je uruchamiasz
• (dobre) testy jednostkowe dają drugi klient kodu, który często podkreśla problemy z projektowaniem, które można pominąć w inny sposób:

Dodaj to wszystko i jeśli mierzysz od momentu powstania do dostawy, a TDD jest znacznie, dużo szybciej - dostajesz mniej wad, podejmujesz mniej ryzyk, postępujesz ze stałą szybkością (co ułatwia ocenę) i lista jest długa .

TDD sprawi, że będziesz szybszy, bez wątpienia, ale nie jest to łatwe i powinieneś pozwolić sobie trochę miejsca na naukę i nie denerwować się, jeśli początkowo wydaje się wolniej.

Na koniec powinieneś spojrzeć na niektóre techniki BDD, aby ulepszyć to, co robisz z TDD. Rozpocznij od funkcji, którą chcesz zaimplementować i przejdź do kodu, pobierając historie, a następnie scenariusze. Skoncentruj się na implementacji scenariusza rozwiązania według scenariusza w cienkich pionowych wycinkach. Takie postępowanie pomoże wyjaśnić wymagania.

Answer 8

IMHO, Twoim głównym problemem jest usunięcie jakiegoś kodu. To jest odpady i to jest to, co należy najpierw rozwiązać.

Być może można prototypować lub używać "rozwiązań kolców" do sprawdzania wymagań i pomysłów, a następnie zastosować TDD na prawdziwym kodzie, gdy wymagania będą stabilne.

Ryzyko polega na zastosowaniu tego i wysłaniu prototypu.

Możesz także przetestować "ścieżkę słoneczną" jako pierwszą i zaimplementować tylko pozostałe, takie jak obsługa błędów ... po tym, jak zostaną spełnione wymagania. Jednak drugi etap wdrażania będzie mniej motywujący.

Jakiego procesu rozwoju używasz? Brzmi zwinnie, ponieważ masz iteracje, ale nie w środowisku, które w pełni je obsługuje.

Answer 9

Joshua Block skomentował coś podobnego w książce "Coders at work". Jego poradą było napisanie przykładów użycia API (o długości strony). Następnie dużo przemyśl przykłady i API, a następnie uzupełnij interfejs API. Następnie napisz specyfikację i testy jednostkowe. Przygotuj się jednak do zmiany interfejsu API i przepisania specyfikacji podczas wdrażania interfejsu API.

Answer 10

TDD będzie, dla niemal każdego, spowolnić początkowy rozwój. Tak więc, jeśli początkowa szybkość rozwoju wynosi 10 w skali 1-10, z TDD możesz uzyskać około 8, jeśli jesteś biegły.

To jest rozwój po ten punkt, który staje się interesujący. W miarę jak projekty stają się większe, wydajność rozwoju zazwyczaj spada - często do 3 w tej samej skali. Dzięki TDD można nadal pozostawać w zakresie 7-8.

Sprawdź "dług techniczny", aby uzyskać dobrą lekturę. O ile mi wiadomo, każdy kod bez testów jednostkowych jest efektywnym długiem technicznym.

Answer 11

Kiedy mam do czynienia z niejasnymi wymaganiami, wiem, że mój kod będzie musiał się zmienić. Posiadanie solidnych testów pomaga mi czuć się bardziej komfortowo, zmieniając mój kod. Ćwiczenie TDD pomaga mi pisać solidne testy, i dlatego to robię.

Chociaż TDD jest przede wszystkim techniką projektowania, ma jedną wielką zaletę w twojej sytuacji: zachęca programistę do rozważenia szczegółów i konkretnych scenariuszy. Kiedy to robię, zauważam, że dość szybko znajduję luki lub nieporozumienia lub brak jasności w wymaganiach. Akt próby pisania testów zmusza mnie do radzenia sobie z brakiem jasności wymagań, zamiast próbować zmieść te trudności pod dywan.

Kiedy mam niejasne wymagania, ćwiczę TDD zarówno dlatego, że pomaga mi to określić konkretne problemy, które muszę rozwiązać, ale także dlatego, że zachęca mnie do pisania kodu, który łatwiej jest zmienić, ponieważ rozumiem więcej co muszę zbudować.