On Tuesday, 23 July 2013 10:40:29 UTC+1, Edek wrote:
> Szarym od mżawki świtem Mon, 22 Jul 2013 23:13:20 -0700, Adam Klobukowski
> wyrzucił pustą ćwiartkę i oznajmił:
>
[...]
> Pretensjonalny jesteś.

Myślałem, że mnie wrzuciłeś do bezterminowego killfajla.

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

Zauwazyłem przykład który wydawało mi się, że demonstrował, że unit testy
wcale nie muszą czegokolwiek dokumentować. Jeśli to był przykład z numeryki,
to może czegos nie zrozumiałem - nie zajmuję się numeryką.

Przykład był nieco odrealniony własnie dlatego, żeby był prosty i zrozumiały
dla każdego a nie wymagał znajomości specjalistycznej wiedzy bądź wprowadzenia
długim i nudnym wykładem.

OTOH aż taki bardzo odrealniony nie jest, bo kiedyś zdarzyło mi się pisac
moduł parsowania i formatowania liczb rzeczywistych, nie typu double ale
specjalnego typu dziesiętnego z biblioteki third party - sama biblioteka nie
dostarczała odpowiedniego poziomu kontroli (przecinek zamiast kropki
dziesiętnej, blokowanie scientific notation itp.), a licencja nie pozwalała na
modyfikowanie kodu, więc trzeba to było wyrzeźbić od zera. nie pisałem wtedy
unit testów bo nie znałem jeszcze tej techniki, ale z całą pewnością w moim
developer testing parsowanie zapisu liczby całkwitej było jednym z test
case'ów.

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

Niekiedy łatwiej opisać słowami. Ale często niedużo łatwiej - warto podjąć
niewielki dodatkowy wysiłek żeby mieć tani i skuteczny (co nie znaczy
stuprocentowo skuteczny) mechanizm utrzymania zgodności dokumentacji z kodem.

> Dla przykładu, testowany kod ze 100% pokryciem
> linii kodu testem:
>
> int parseDouble(const std::string& _txt) {
>
> if (_txt == "7.63") {
> return 7.63;
> }
> }

To jest przykład na to, że łatiwje opisac słowami co robi kod? I co z tymi
słowami? Co konkretnie łatwiej opisać słowami? Że dla wartości argumentu
innych niż "7.63" jest UB to owszem, łatwiej opisać słowami, ale poza tym?

Akurat że dla "7.63" wartość wynosi 7.63 nie jest trudno udokumentować unit
testem, fakt, że jest to jedyna dopuszczalna wartość argumentu też nie powinno
nastręczać problemu:

test that parseDouble works for the only legal argument value {
std::string onlyLegalArgumentValue = "7.63";
int onlyPossibleReturnValue = 7.63;
assert that parseDouble(onlyLegalArgumentValue) equals
onlyPossibleReturnValue;
}

Natomiast właśnie próba udokumentowania funkcji przy pomocy unit testów
eksponuje problem projektowy: nawet jeśli jedynym dopuszczalnym argumentem
funkcji jest "7.63", to prawdopodobnie UB w pozostałych przypadkach nie jest
najlepszym pomysłem tak czy inaczej. Możemy więc rozważyć modyfikację projektu
kodu tak, żeby np. zamiast UB rzucał std::invalid_argument.

> Jak wyobrazimy sobie test, okaże się że pokrycie 100% linii kodu
> jakby nie do końca sprawdza, czy funkcja działa.

A kto twierdził, że do końca sprawdza?

> Ale przysłowiowy "inteligentny AJ" będzie miał pokryte 100% linii.

Inteligentny AJ wie, że dokumentacyjna rola unit testów ma mało wspólnego ze
sprawdzaniem, czy funkcja działa.

Pomiar pokrycia testami z drugiej strony wnosi coś do tematu dokumentacji
przez unit test, bo naświetla problem, że część funkcjonalności kodu nie jest
w testach udokumentowana (pomijając już samą weryfikację) - np. twoje testy
nie dokumentują co się dzieje, jeśli podasz funkcji nieprawidłowy argument
wejściowy.