On 21/12/2011 15:26, Maciej Sobczak wrote:
>
> 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?

Oczywiście 100% gwarancji nie ma, ale wyobraź sobie, że o tym problemie
ktoś pomyślał. Przede wszystkim robienie testów przed napisaniem kodu
daje ci podstawowy test testu, mianowicie taki, że test nie przechodzi
kiedy tego, co testujesz jeszcze nie ma, a przechodzi, kiedy
funkcjonalność jest zaimplementowana. Druga sprawa jest taka, że do kodu
produkcyjnego stosuje się praktyki, które wymuszają sprawdzenie go przez
drugą osobę, i te same praktyki można stosować do testów - pair
programming albo code review. Acceptance tests pisze się dodatkowo razem
z OSCR-em i być może review-uje je product owner.

Z praktycznego punktu widzenia to nie jest jednak tak, że różnica jest
dopiero między programem z błędami, a programem, który w ogóle nie ma
żadnych błędów. Dużą różnicę robi ilość błędów, a przy TDD błąd trudniej
popełnić, bo oprócz tego, że trzeba zrobić błąd w kodzie, to jeszcze
trzeba zrobić błąd w teście, i to jeszcze musi być taki błąd, który
spowoduje, że błąd w kodzie nie zostanie wychwycony. O ile programista
ma dobre zrozumienie, co program ma robić, a ewentualne błędy
spowodowane są przez nieuwagę, to prawdopodobieństwa popełnienia tych
wszystkich błędów będzie zdecydowanie mniejsze, niż tylko tego w kodzie
programu.

> 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? :-)

Bo testy to nie kod produkcyjny.

> 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?

Banalnie - zakładasz poziom pewności, np. 5 sigma i robisz skwantyzowany
soak test - generujesz liczby, wrzucasz w odpowiednie przedziały, jak
wygenerujesz odpowiednio dużo, to sprawdzasz, czy w każdym z przedziałów
jest odpowiednia ilość plus minus błąd. Jak ci się nie chce porządnie
liczyć błędów, to robisz "na oko" i ewentualnie korygujesz. Na tym
schemacie możesz zrobić unit test, który ci to sprawdza w pół sekundy, i
soak test, który leci godzinę.