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ą.
Pandemia COVID-19 zmieniła wszystko. Większość z nas pracuje zdalnie. Pomożemy wam odnaleźć się w tej nowej rzeczywistości. Mamy doświadczenie w pracy „po kablach”, którymi chcemy się podzielić. Co ważne, choć to doświadczenie pochodzi z IT, to można je zastosować do każdej branży.
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?