On Dec 21, 11:51 am, Roman W <b...@g...pl> wrote:
> Na grupie padaly stwierdzenia, ze wymagania wobec programu mozna opisac w formie
testow.
>
> Zalozmy, ze mamy zaimplementowac funkcje (na przykladzie C++)
>
> double calculate_stuff(const std::vector<double>& data);
>
> z warunkiem "ma sie wykonywac w czasie liniowym w rozmiarze wektora data".
>
> Jak napisac test, ktory sprawdza czy ten wymog jest spelniony?

Nie pisać.
To jest jedna z tych rzeczy, którą łatwiej zrobić, niż sprawdzić
(podobnie, jak wspomniany pogłos z filharmonii w Koluszkach).
Pamiętajmy, że tworzenie testów też kosztuje, o czym zwolennicy TDD
często zapominają.

Przy okazji, powstaje również problem, jak sprawdzić, że test sprawdza
to co miał sprawdzać? Bo koszt testów nie sprowadza się tylko do ich
objętości, ale również do zrozumienia, jak zrobić test. Kto sprawdzi
test?
I w ogóle to dlaczego pisanie testów, których objętość może
przekroczyć właściwy projekt (co TDDowcy przyznają) nie odbywa się
według tej samej metody, która niby jest dobra do wszystkiego? Tzn.
dlaczego testów nie pisze się według TDD? :-)

Oprócz złożoności liniowej i pogłosu w filharmonii w Koluszkach,
takich przykładów jest znacznie więcej. Np. mamy napisać generator
liczb losowych o zadanym rozkładzie - jak to sprawdzić przez TDD?
Tutaj również łatwiej jest to zrobić poprawnie przez właściwą
konstrukcję, niż stworzyć poprawny test.

Takich przykładów może być nieskończenie wiele, a to oznacza, że jest
nieskończenie wiele projektów, dla których TDD jest niewłaściwym
podejściem.
Niespodzianka? Ani trochę.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com