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

do góry

On Tuesday, 23 July 2013 09:30:21 UTC+1, Adam Klobukowski wrote:
> On Tuesday, 23 July 2013 09:26:06 UTC+2, Andrzej Jarzabek wrote:
>
> > Owszem, ale też zasygnalizują ci, że funkcja z 60 parametrami czy klasa
> > z 60 setterami to prawdopodobnie nienajlepszy pomysł i powinieneś rozbić
> > problem na składowe zagadnienia, które będą realizowane przez osobne
> > jednostki kodu (funkcje, klasy), które będą miały swoje unit testy,
> > przez co nie ma potrzeby sprawdzania testami kombinacji warunków
> > brzegowych itp. dla 60 parametrów.
>
>
>
> Podzielone to owszem jest, testy też, ale i tak istotne jest to co jest
> finalnie na wyjściu. Po prostu unit testy nie dają gwarancji że jeśli
> każde 10% ze 100% działa ok, to całe 100% będzie działać ok.

Tak. Nie. Znaczy:

Mówiliśmy o dokumentacyjnej, nie weryfikacyjnej roli testów. Dokumentacja nie
jest od dawania gwarancji, jest od udzielania informacji, w tym przypadku jak
dana funkja czy klasa działa.

Testy tak w ogóle (nie tylko unit testy) nie dają 100% gwarancji że coś
działa, wykrywają że nie działa z pewnym prawdopodobieństwem (redukują
ryzyko niedziałania).

Jeśli masz dobry projekt, sensowne testy i konsekwentnie trzymasz się
dyscypliny TDD, to unit testy redukują ryzyko niedziałania całości w bardzo
sensownym stopniu. Jeśli ma się powody przypuszczać, że testy mają luki w
sprawdzaniu czy testowane jednostki faktycznie działają razem żeby uzyskać
pożądaną funkcjonalność końcową, to warto pomyśleć o dopisaniu unit testów
które to sprawdzają. Jeśli projekt kodu (klas) jest taki, że trudno to zrobić,
warto pomyśleć o zrewidowaniu projektu. Kluczowe hasła tutaj: dependency
injection, mock objects.

Unit testy nie zabezpieczają przed sabotażem, bądź w postaci celowego zepsucia
kodu, bądź działania bezmyślnego, łamania dyscyplin itd.

Tak, owszem, opócz unit testów dobrze/nalezy mieć testy wyższego poziomu:
smoke/system/acceptance/functional/integration tests. Dlatego, że testują
rzeczy, których unit testy nie magą wyłapać (lub nie jest to praktyczne), ale
też dlatego, że moga pełnić funkcję dokumentacyjną innego rodzaju niż unit
testy. Unit testy dokumentują projekt kodu - co robią i jak się używa
poszczególnych klas, funkcji itd. Inne testy mogą dokumentowac funkcjonalność
biznesową, architekturę systemu, protokoły zewnętrznych interfejsów,
zachowania, co tam jeszcze.

do góry

Użytkownik "Edek" napisał w wiadomości grup
dyskusyjnych:ksk7qs$d3h$...@n...news.atman.pl...

>Myślę, że nie rozpatrujesz Agile z punktu widzenia teorii gier.

No to może ja spróbuję ;)

Jestem klientem, mam w kieszeni (aktywa, pasywa, portfel itd.) 1000 euro na
bardzo prosty program w ECMA-skrypcie, bo potrzebuję.

Szukam wykonawcy - znajduję takiego od Agile. Moje pierwsze pytanie: "da się
zrobić za 200 euro"? Odpowiedź: "nie". Na to ja: "a za 500 euro"? Odpowiedź:
"nie, łącznie to będzie trochę mniej, a może trochę więcej niż 800, może 900
euro". Ok, jest dobrze. To co mam starczy na zapłacenie za program (więcej
nie mam, bo po prostu nie mam).

Przychodzi do szczegółów... "my stosujemy Agile". Wow! Pytam się co to jest.
Dowiaduję się, że cena nie będzie fixed, ale że zapłacę za robociznę i
materiały. Ok. Ale upewniam się, że nie więcej niż 900 euro. Ba! Mogę być
zupełnie szczery - i po prostu powiedzieć, że te 1000 euro to dostałem po
dziadkach, a ogólnie poza tym nie mam ani grosza.

I teraz wchodzimy z teorią gier.

Wykonawca wie, że jak nakręci cenę (przez koszt materiałów, koszt robocizny
i marżę/zarobek) powyżej 1000 euro, to ja mu nie zapłacę, bo zwyczajnie nie
mam z czego. Nawet jeżeli będzie próbował - sąd, komornik, windykacja
jakaś - to prędzej zbankrutuję, niż zapłacę.

Z drugiej strony, jeżeli jego rzeczywiste koszty - choć tego nie wiedział w
chwili dojścia do porozumienia - wyniosą zaledwie 10 euro (np. okaże się, że
już taki program miał napisany) - to jaki ma interes w tym, aby nie chcieć
zarobić tych 890 euro, a może 990 euro więcej? Przecież on wie, że ja mogę
tyle dać. A ja wiem że on może tyle chcieć i jakoś to już zaakceptowałem. A
on wie że ja wiem. Itd.

Wynik: 1000 euro.

do góry

Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
dyskusyjnych:kskic9$o0a$...@s...invalid...

>ale stwierdziłem że dla higieny ogólnej lepiej przestać czytać i
>odpowiadać.

Cóż, zawsze twierdziłem, że znaczna część ludzi w głębi duszy to jednak
analfabeci.

Swego czasu zainteresowałem się nieco metodykami zwinnymi, czyli także
Agile. Niezbyt dogłębnie, ale wystarczając, aby wiedzieć "dlaczego NIE będę
używac Agile". Oczywiście - to że mi akurat Agile się nie przyda - to nie
oznacza, że Agile jest do niczego nie przydatne... mogę sobie wyobrazić, że
dla niektórych będzie po prostu dobrym wyborem. Może, cyt. "baza danych
szlauchów i kaloszy" (czy to AL pierwszy użył kiedyś tego określenia?) to
jest właściwe miejsce dla stosowania Agile? Może programy używane przez
banki? Nie wiem. Będę kiedyś musiał zajmować się szlauchami to być może
"wrócę do" Agile.

Co takiego jest dziwacznego w Agile? To, że jest to parareligijna
fascynacja. Coś z Amwaya czy innego takiego. Agilicy czują się dobrze we
własnym gronie, mają dość ograniczony zasób argumentów (wyuczone na pamięć z
paru książek napisanych przez innych Agilików), nigdy nie podają jakie sami
projekty realizowali i ogólnie wydają się być dość daleko od "prawdziwego
przemysłu" (jakim go rozumie np. AL). Gotowi są do "nawracania" każdego na
Agilizm... a to trochę dziwne, bo gdybym miał cudowny "klucz do sukcesu", to
raczej sam bym go używał - a nie dzielił nim z konkurencją za friko.

Jest jeszcze jedna sprawa: my tu sobie tak z nudów dyskutujemy. Ale mam
podejrzenie, graniczące z pewnością, że kozactwo tutejsze - gdyby rozmawiało
z autentycznym prezesem o zleceniu wartym ćwierć miliona euro - to nie
zaczynałoby negocjacji od stwierdzeń "pan prezes jest idiotą", "za tyle to
mi się nie chce", "pan źle zarządza firmą". A gdyby jednak, to rozmowy
musiałby się szybko zakończyć - żaden prezes nie pozwoli sobie na takie
rzeczy, zwłaszcza jeżeli słuchają jego podwładni.

do góry

Szarym od mżawki świtem Tue, 23 Jul 2013 12:28:12 +0200, slawek wyrzucił
pustą ćwiartkę i oznajmił:

> Użytkownik "Edek" napisał w wiadomości grup
> dyskusyjnych:ksk7qs$d3h$...@n...news.atman.pl...
>
>>Myślę, że nie rozpatrujesz Agile z punktu widzenia teorii gier.
>
> No to może ja spróbuję ;)
[...]
> I teraz wchodzimy z teorią gier.
>
> Wykonawca wie, że jak nakręci cenę (przez koszt materiałów, koszt robocizny
> i marżę/zarobek) powyżej 1000 euro, to ja mu nie zapłacę, bo zwyczajnie nie
> mam z czego. Nawet jeżeli będzie próbował - sąd, komornik, windykacja
> jakaś - to prędzej zbankrutuję, niż zapłacę.
>
> Z drugiej strony, jeżeli jego rzeczywiste koszty - choć tego nie wiedział w
> chwili dojścia do porozumienia - wyniosą zaledwie 10 euro (np. okaże się, że
> już taki program miał napisany) - to jaki ma interes w tym, aby nie chcieć
> zarobić tych 890 euro, a może 990 euro więcej? Przecież on wie, że ja mogę
> tyle dać. A ja wiem że on może tyle chcieć i jakoś to już zaakceptowałem. A
> on wie że ja wiem. Itd.
>
> Wynik: 1000 euro.

Dobre. Skoro już jesteśmy ordynarni, wprowadzę małe elementy kulturalne,
mam na myśli kulturę niską albo - skoro miało być ordynarnie - zwykłe
chamskie kompleksy i szerszy obraz.

Jeżeli wykonawca ma już taki program napisany, może zaproponować cenę 400-500
euro. Z tym że w swojej branży tanich szczurków takie zachowanie uchodzi za
naiwność, straciłby szacunek i nie mógłby się chwalić kolegom, jak to kogoś
wydymał. Więc będzie stawał na rzęsach żeby dymać, za 500 euro.

No ale powiedzmy, że wykonawca jest jednak na poziomie, co zrobi zamawiający?
Ano zakompleksiony zamawiający się oburzy. Jak to, mam płacić za coś co on ma
i nic go nie koszutje 500 euro? Znowu, szacunek, kto kogo wydyma, itd. .
Woli poszukać "innego wykonawcy niż takiego gnoja", nawet jeżeli będzie
musiał zapłacić 500 euro więcej - płaci bo może, jest panem świata.

I tym sposobem ogólna kultura i panujące zwyczaje potrafią zatruwać wszystkim
życie. Czy się przykryje sprawę gładką gadką o TDD w Agile czy nie. Jak
widać na przykładzie, nie wystarczy 50% ludzi na poziomie, potrzeba 75%
(50% że zamawiający jest rozsądny, z tych 50% 50% że drugi jest rozsądny).
Natomiast jeżeli obaj są rozsądni i taka postawa jest szanowana, obaj
będą się polecali na przyszłość innym, pytanie tylko, jakie jest
prawdopodobieństwo ich spotkania i co myślą inni w tej grze.

--
Edek

do góry

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.

do góry

On 2013-07-23 00:09, Edek wrote:
> Obawiam się, że nie zrozumiałęś przykładu. Unit testy tylko pokazują,
> że dla *tych wybranych przypadków* działa.

Dokładnie to twierdzę. Ale twierdzę też że w duzym kodzie funkcja
dokumentowania jest wazniejsza niż weryfikacji.

> I nie, unit testy w praktyce ani nie są pewne ani też praktycznie
> nigdy nie pokrywają wszystkich przypadków.

*Żadne* tgesty nie pokrywają *wszystkich* przypadków i nikt tak nie
twierdzi.

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

Unit testy pisze się z bardzo wielu powodów. Pomoc przy refaktoringu
jest ważna, ale mam wrażenie że im większy kod tym więcej jest zastosowań.

do góry

On 2013-07-23 07:33, Roman W wrote:
> Unit testy to jest forma dokumentacji, ale bardzo niskopoziomowa i
> uzyteczna wyłącznie dla programistów.

Komantarze w kodzie to jest forma dokumentacji, ale bardzo
niskopoziomowa i użyteczna wyłacznie dla programistów. Oh wait ...

do góry

Szarym od mżawki świtem Tue, 23 Jul 2013 21:23:01 +0200, Sebastian Biały
wyrzucił pustą ćwiartkę i oznajmił:

> On 2013-07-23 07:33, Roman W wrote:
>> Unit testy to jest forma dokumentacji, ale bardzo niskopoziomowa i
>> uzyteczna wyłącznie dla programistów.
>
> Komantarze w kodzie to jest forma dokumentacji, ale bardzo
> niskopoziomowa i użyteczna wyłacznie dla programistów. Oh wait ...

Niektórzy mówili tu o unitach jako dokumentacji technicznej będącej
wymaganiem kontraktu. Czego ja nie jestem wielkim zwolennikiem,
ale może jak ktoś coś takiego chce mieć w kontrakcie to żyjemy
w wolnym kraju. Raczej spotkałem się z acceptance tests, a to
zdecydowanie nie są unity.

--
Edek

do góry

Użytkownik "Edek" napisał w wiadomości grup
dyskusyjnych:kslomf$kj2$...@n...news.atman.pl...

>Natomiast jeżeli obaj są rozsądni i taka postawa jest szanowana, obaj
>będą się polecali na przyszłość innym, pytanie tylko, jakie jest

Oczywiście, można "w promocji". Tzn. zamiast wydać na reklamę x PLN można
liczyć na reklamę szeptaną gdy obniżymy cenę do y-u PLN, co się opłaci
jeżeli x > u. Można liczyć na to, że dając coś za cenę poniesionych kosztów,
lub nawet niżej (freeware!), zyskuje się wizerunkowo lub jakieś korzyści
niematerialne (np. dobre samopoczucie, czy jakąś formę aureoli nad głową).

do góry