On Tuesday, 23 July 2013 02:16:02 UTC+2, Andrzej Jarzabek wrote:
> On 22/07/2013 23:09, Edek wrote:
>
> > Szarym od mżawki świtem Sat, 20 Jul 2013 10:53:26 +0200, Sebastian Biały
>
> > wyrzucił pustą ćwiartkę i oznajmił:
> >
> >> Ale już taki test:
> >>
> >> assert( parseDouble( "1.0" == 1.0 ) );
> >> assert( parseDouble( "1E0" == 1.0 ) );
> >> expect_throw( parseDouble( "1e0" ) );
> >> expect_throw( parseDouble( "1,0" ) );
>
> >>
> >> ... ślicznie dokumentuje.
>
> >
> > Obawiam się, że nie zrozumiałęś przykładu. Unit testy tylko pokazują,
> > że dla *tych wybranych przypadków* działa. Jest wiele przypadków
> > kodu gdzie to wystarcza, ale jest też wiele przypadków, gdzie
> > albo nie ma skończonej liczby przypadków (czyli też unitów), albo
>
> > nic się w ten sposób nie dokumentuje - bo to trochę tak jakby zamiast
> > książki z przykładami mieć same przykłady.
>
> Edek myli weryfikację z dokumentacją. Test, owszem, weryfikuje
> szczególne przypadki, ale dobrze napisany dokumentować może ogólne
> reguły które te przypadki reprezentują.
>
> Dokumentacyjną rolę w testach pełni przede wszystkim nazwa testu, ale
> też cały jej zapis:
>
> test parseDouble parses decimal integer representation {
> int integer = 83;
> string representation = "83";
> assert that parseDouble(representation) equals (double)integer;
> }
>
> Chcąc się dowiedzieć co robi parseDouble i dla jakich przypadków daje
> jakie wyniki, i korzystając z unit testów jako dokumentacji, jełop
> wyczyta z powyższego tylko informację, że dla wejścia "83" daje liczbę
> równą (double)83, ale inteligentny czytelnik wyczyta więcej.

Yhm. Dla takiego trywialnego przypadku jest to proste. Wyobraź sobie że masz
obliczenia gdzie możesz mieć sporo danych wejściowych, ok. 60 parametrów
konfiguracyjnych obliczeń a klient zwraca uwagę na 12 cyfrę po przecinku.
Udokumentować to możesz, ale ta dokumentacja nie sprawdzi Ci poprawności obliczeń dla
wszystkich przypadków. Unit testy, jak są dobrze napisane, maja taką szansę.

AdamK