🚀 go-pugleaf

Dnia Sun, 11 Jun 2006 15:20:49 +0200, Adam Karpierz skrobie:
> PS: Gdybym byl szefem projektu to nawet bylbym w stanie posunac
>         sie do tego zeby wy.. programiste z pracy za uporczywe ignorowanie
>         zakazu implementacji _przed_ napisaniem testow.
>         OK, wiem ze skrajnosc ale..

Ja tam skrajności nie lubię. Często mi się zdarzało coś takiego, że
konstrukcja interfejsu była mocno zmieniana pod wpływem próbnych
implementacji. Po prostu czasami nie byłem w pełni świadom np. tego, jakie
argumenty ma przyjmować funkcja, bo nie wiedziałem do końca, co jej w
rzeczywistości będzie potrzebne do poprawnego działania. A "z dupy" strzelić
interfejs, napisać potem do niego test, a potem poprawiać po kilka razy test,
bo po napisaniu implementacji trzeba było poprawić interfejs - to też nadmiar
niepotrzebnej roboty. Przynajmniej przydałoby się wstępnie naszkicować
implementację i określić, co jej jest potrzebne. Mając to dopiero wtedy wiemy,
jaki na pewno jest interfejs, a do niego możemy napisać test.

My to robiliśmy dokładnie tak, że najpierw mając określone wymagania (czyli:
co to nasze coś ma robić) opracowywaliśmy plany testów ("jak sprawdzić, że
robi rzeczywiście"), potem próbny szkic implementacji (mając testy nawet
łatwiej się wtedy pisze, bo się pisze "pod klienta" :), wtedy robi się test
dostosowany do implementacji i doprowadza się implementację do działania (test
i implementację nawet często pisały inne osoby). Tak nawet jeszcze dokładniej,
to często test potrzebował mieć jakieś dodatkowe "ostubowanie" i to właśnie
"ostubowanie" pisało się jeszcze przed implementacją.



-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"