Niekiedy można spotkać się z opinią, że TDD spowalnia wytwarzanie oprogramowania. Jeśli chciałbyś powtórzyć eksperyment i samodzielnie dowieść, że TDD się nie opłaca, poniżej zamieszczam gotową receptę:
- pisz testy po napisaniu kodu produkcyjnego
- nie rób żadnej wstępnej analizy problemu, przemyśleń ani odrobiny projektowania (przemiel 100% projektowania przez cykl TDD dzięki czemu będziesz miał okazję sto razy zmieniać design i testy)
- samodzielnie odkrywaj jak efektywnie pisać przypadki testowe, dzięki czemu zajmie Ci to kilka lat (pod żadnym pozorem nie oglądaj screencastów i nie czytaj książek)
- upewnij się, że testy ładują się co najmniej pół minuty zanim faktycznie zaczną testować (możesz to łatwo osiągnąć np. ładując cały framework i pracując na powolnym dysku HDD)
- zadbaj, by każda funkcjonalność była testowana przez GUI (przez sterowanie przeglądarką lub oknem GUI na pulpicie)
- zadbaj, by wszystkie testy były uzależnione od bazy danych
- za każdym razem ręcznie poluj na plik testowy odpowiadający kodowi produkcyjnemu i vice versa
- za każdym razem nawiguj pomiędzy pulpitami, oknami i zakładkami w poszukiwaniu skryptu startującego testy
- im mniej klas tym lepiej, staraj się by każda klasa miała bogaty zestaw niezwiązanych odpowiedzialności (dzięki temu będziesz mógł spędzić nieograniczoną ilość czasu na pisaniu testów)
- pisz piękne opisy kroków w Cucamber nawet jeśli klient ma w dupie czytanie Twojej specyfikacji funkcjonalnej (a zwłaszcza gdy w ogóle nie masz klienta)
Nieśmieszne. Gdyby to wydrukować i powiesieć gdzieś na scianie w biurach firm IT, wielu by właśnie tak postępowało.
Ale gratuluje podejścia do tematu od tej drugiej strony zamiast “jak zyskać … robiąc TDD”.
Masz rację, wielu mogłoby to potraktować poważnie :-)