Szarym od mżawki świtem Mon, 22 Jul 2013 23:13:20 -0700, Adam Klobukowski
wyrzucił pustą ćwiartkę i oznajmił:

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

Pretensjonalny jesteś.

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

Nie trzeba szukać tak daleko. Roman W podał przykład z numeryki, który
jest znacznie bliżej codziennej rzeczywistości niż dokumentowanie
co robi "parseDouble".

Nie twierdzę, że unit testy nie mają szansy dokumentowania kodu,
w jakimś stopniu dokumentują (i to ja mylę testy z dokumentacją?).
Natomiast znacznie łatwiej jest opisać słowami co robi dany kod
i uzyskać pełny opis. Dla przykładu, testowany kod ze 100% pokryciem
linii kodu testem:

int parseDouble(const std::string& _txt) {
if (_txt == "7.63") {
return 7.63;
}
}

Jak wyobrazimy sobie test, okaże się że pokrycie 100% linii kodu
jakby nie do końca sprawdza, czy funkcja działa. Z punktu widzenia
metryk, testy nie pokrywają 100% branchy ani 100% funkcjonalności.
Ale przysłowiowy "inteligentny AJ" będzie miał pokryte 100% linii.

--
Edek