Ponoć kiedy kod jest już napisany nie da się stwierdzić, czy był pisany w modelu TDD. Jest jednak kilka śladów zbrodni, które pozostają. Na przykład testy sprawdzające zbyt wiele rzeczy na raz i zakładające, że czytelnik posiada wiedzę tajemną.

Ponoć kiedy kod jest już napisany nie da się stwierdzić, czy był pisany w modelu TDD. Jest jednak kilka śladów zbrodni, które pozostają. Na przykład testy sprawdzające zbyt wiele rzeczy na raz i zakładające, że czytelnik posiada wiedzę tajemną.
Oto pierwszy warsztat 🔧 migawki. Celem warsztatu jest poprawienie prostego skryptu i pokazanie jak rozwiązujemy codzienne problemy oraz na co zwracamy uwagę przy ocenie jakości kodu. “Pierwsza wersja wszystkiego to śmieci”, my, też przejdziemy przez parę iteracji, ale mam nadzieje, że efekt końcowy zaskoczy Cię tak samo jak mnie😱
W tej części naszego cyklu o TDD dowiecie się dlaczego warto rozbijać pracę na etapy i co test driven development ma wspólnego ze Scrumem.
Rysownicy szkicują. Pisarze robią konspekty. Naukowcy stawiają hipotezy. Co robią programiści? Zwykle idą na żywioł. Strach przed waterfallem poszedł tak daleko, że przestaliśmy planować cokolwiek. Tymczasem dobrze jest mieć mechanizm, który będzie co kilka minut przypominał nam, gdzie jest nasz cel. Tym właśnie jest test driven development.
Jakie problemy napotkaliśmy na początku? W czym nam pomogła? Kiedy na pewno z niej nie skorzystamy?