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.

I zanim się ktoś czepnie - jeszcze raz, owszem, ten test nie _dowodzi_,
że funkcja parsuje reprezentacjee jakichkolwiek liczb całkowitych innych
niż 83, ale to dokumentuje. Komentarz w kodzie, dokument w Wordzie czy
schemat w Enterprise Architect w ogóle nie dowodzą czegokolwiek jeśli
chodzi o dokumentowany kod, a dokumentować mogą.

> I nie, unit testy w praktyce ani nie są pewne ani też praktycznie
> nigdy nie pokrywają wszystkich przypadków. Pokrycie 100% linii bywa
> górną granicą,

Raczej ciężko, żeby unit testy pokrywały więcej niż 100% linii.

> a często nawet nie. Unit testy pisze się głównie
> dla szybkiego wyłapania oczywistych regresji.

Jest to jeden z powodów. Rola dokumentacyjna jest również istotna. Co
prawda tę samą treść możnazapisać w komentarzu czy w Wordzie, ale zaleta
dokumentacji w unit testach jest taka, że komentarze czy dokumenty mogą
z czasem rozjechać się z rzeczywistością - nie tylko z powodu regresji,
ale mogą przede wszystkim stać się nieaktualne. Sensownei dobrane unit
testy z wysokim prawdopodobieństwem zaczną w danej sytuacji failować, co
zasygnalizuje problem i pozwoli programiście stwierdzić czy ma do
czynienia z regresją czy z dezaktualizacją - i w zależności od przypadku
poprawić testowany kod lub test.

W reżimie TDD unit testy pełnią też dodatkowe role - choćby pomagają
utrzymać wysoką jakość kodu. Na przykład fakt, że do jakiegoś kawałka
kodu ciężko napisać unit test często sygnalizuje problemy z projektem -
np. zawierająca ten kod funkcja próbuje robić kilka różnych rzeczy, ma
niejawne zależności itd.