On Wed, 21 Dec 2011 07:26:49 -0800 (PST), Maciej Sobczak
<s...@g...com> wrote:

>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ę.

TDD jest po to aby zapewnic zgodnosc kodu ze specyfikacja i po nic
wiecej

A.L.