Szarym od mżawki świtem Sat, 20 Jul 2013 10:53:26 +0200, Sebastian Biały
wyrzucił pustą ćwiartkę i oznajmił:

> On 2013-07-19 21:53, Roman W wrote:
>> Test może byc typu
>> x = 4.5;
>> expected = 10.4;
>> assertEquals (expected, f (x));
>> I jaka ma wtedy wartość jako dokumentacja?
>
> Przypuszczam że zbliżoną do:
>
> // funkcja f
> // przyjmuje: double - pierwszy parametr
> // zwraca: double
> int f( int, char* ) { }
>
> Czyli żadną.
>
> 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.

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ą, a często nawet nie. Unit testy pisze się głównie
dla szybkiego wyłapania oczywistych regresji.

--
Edek

do góry

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.

do góry

On 23/07/2013 00:35, Roman W wrote:
> On Mon, 22 Jul 2013 21:13:25 +0200, "slawek" <h...@s...pl> wrote:
>> Ja za stary troll jestem, aby samoocenę kształtowały mi jakieś
> marudzenia
>> tułającego się od banku do banku (choćby inwestycyjnego). Niemniej
> jednak
>
> A ty gdzie sie tulasz? Ukrywasz sie ze pseudo i zygasz.

Sławkowi skończyły się jakiekolwiek argumenty, więc postanowił
zredukować dyskusję do wyzwisk, personalnych zaczepek i pieprzenia bez
sensu. Już po poprzednim poście stwierdziłem, że mógłbym co prawda
napisać mu gdzie pieprzy bez sensu i odpowiedzieć obelgami na obelgi,
ale stwierdziłem że dla higieny ogólnej lepiej przestać czytać i odpowiadać.

do góry

Unit testy to jest forma dokumentacji, ale bardzo niskopoziomowa i
uzyteczna wyłącznie dla programistów.

RW

do góry

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

Oczywista, to jest dokumentacja, która częściowo zastępuje tradycyjny
"design document" i dokumentację w komentarzach.

do góry

W dniu 2013-07-19 15:55, A.L. pisze:
> On Fri, 19 Jul 2013 10:36:07 +0000 (UTC), "Stachu 'Dozzie' K."
> <d...@g...eat.some.screws.spammer.invalid> wrote:
>
>> On 2013-07-19, slawek <h...@s...pl> wrote:
>>> Użytkownik "Adam Klobukowski" napisał w wiadomości grup
>>> dyskusyjnych:2be9313c-d656-4eed-b10a-0d32a7b43781@go
oglegroups.com...
>>>
>>>> Od zawsze? Zmiana wymagań w klasyczynych metodach wytwarzania
>>>> oprogramowania to zawsze problem, bo założeniem jest że wymagania nie
>>>> powinny się zmieniać. W Agile nigdy, bo >założenie jest że wymagania się
>>>> zmienią.
>>>
>>> Czyli uważasz, że "koszt zmiany w Agile jest zerowy"?
>>
>> Nie widzę z czego taki wniosek wyciągnąłeś. Stosując wprost ten tok
>> rozumowania: jeśli musisz jeść, to znaczy że jedzenie jest darmowe.
>>
>> W klasycznych metodach zmiana wymaga wynegocjowania załącznika do umowy,
>> czyli trzeba zaprząc proces biznesowy, co *zawsze* zauważalnie podnosi
>> koszt operacji[*].
>>
>> Agile zakłada, że skoro zmiany pojawiają się i pojawiać się będą, to
>> trzeba je uczynić *tańszymi* niż do tej pory -- najprościej przez
>> usunięcie procesu biznesowego z drogi.
>
> Co to znaczy "usuniecie procesu biznesowego z drogi"?... Znaczy, praca
> programisty nad zmianami nie kosztuje ani pieneidzy ani czasu?

To znaczy, że zaobserwowano, że obudowanie każdej zmiany w sztywny
proces biznesowy kosztuje znacznie więcej, niż wynegocjowanie
w procesie biznesowym rozwiązania: "w następnym miesiącu robimy takie
zmiany, jakie okażą się potrzebne i możliwe do zrealizowania, nie
wnikamy teraz co to jest". Zmiany są oczywiście kontrolowane,
dokumentowane i co tam jeszcze akurat danemu klientowi potrzeba. Tyle,
że nie siadamy do stolika żeby negocjować kolejne N aneksów do umowy.
Ten stolik to właśnie wyeliminowany proces biznesowy, który kosztuje.
Potrzebny jest oczywiście, gdy klient i wykonawca cały czas walczą,
a nie współpracują.

--
Paweł Kierski
n...@p...net

do góry

W dniu 2013-07-22 16:40, slawek pisze:
> Użytkownik "Paweł Kierski" napisał w wiadomości grup
> dyskusyjnych:ksipns$tfd$...@s...invalid...
>
>>> 2. Programy robione ad hoc w jednoosobowym "zespole". Dotyczy także
>>> zespołu dwuosobowego.
>
>> Pytanie bardziej konkretne - co z Agile będzie przeszkadzało w takim
>> projekcie?
>
> Kluczowe jest "ad hoc" - czyli np. programiki mające wszystkiego 100
> linijek... albo nawet jedną. Nic nie będzie przeszkadzało. Ale nic też
> Agile nie pomoże.
>
> Doraźnie tworzone jednorazówki. Oczywiście, można użyć Agile i do "99
> bottles"...

OK - ale czy tu w ogóle możemy mówić o jakimkolwiek prowadzeniu
projektu? BTW - zdarzyło mi się przy programie 100 linijkowym
(aktualnie ma chyba kilkadziesiąt więcej) pomyśleć: "Czy na pewno
potrzebuję w tej chwili wszystkich czterech funkcjonalności, czy trzy
pierwsze mi wystarczą?".

Ogólnie - nie ma tu dyskusji.

>> Poufność - to już zupełnie nie w temacie. Jak sposób prowadzenia
>> projektu ma mieć wpływ na poufność?
>
> Jeżeli dobrze zrozumiałem, to Agile polega na iteracjach. Mogę sobie
> wyobrazić jednak zastosowania, które wymagają filozofii "wszystko albo
> nic". Nie można mieć programu, który nie jest jeszcze całkiem gotowy,
> ale już jest zaszyty w rozruszniku serca. Podobnie nie można mieć
> programu, który "trochę" chroni np. wrażliwe dane z dużej bazy itp.
> Takie rzeczy wolno uruchamiać (w docelowym środowisku) tylko wtedy, gdy
> są w 100% a może nawet 200% gotowe. Dlatego metodyka zakładająca
> "zrobimy i w razie czego będziemy poprawiać" może być nie akceptowalna -
> "w razie czego" straty będą poważne, nieodwracalne i niewybaczalne.

Widzę podstawowy błąd w rozumieniu Agile. To nie jest "zrobimy
i w razie czego będziemy poprawiać". To jest "zrobimy *teraz* to, co
absolutnie niezbędne, najlepiej jak potrafimy". Tak przypuszczałem, że
w tym podwątku dojdziemy do problemów integracji i testowania całych
systemów. W takich wypadkach można nieco złamać ortodoksję - dalej
pracujemy w iteracjach, ale nie upieramy się, że cały system działa
i jest po każdej iteracji gotowy do release'u. Bez konkretnego przykładu
trochę trudno rozmawiać. Prawie na pewno da się z takiego systemu
wykroić elementy niekrytyczne - te można już realizować w zależności
od potrzeb.

>> produkt w kierunku realizacji tego celu, to czemu nie skanalizować
>> wysiłków korzystając z elementów Agile?
>
> Jeżeli już robiłbym coś za friko, to nie po to, aby ktoś mógł się bawić
> w mojego szefa z tego powodu. Czyli - macie za darmo mój czas i
> doświadczenie - ale to ja ustalam ile, gdzie i jak to wam daję. I czy w
> ogóle. To, moim zdaniem, nie współbrzmi ze słowem "dyscyplina", a
> przecież Agile dyscyplinuje uczestników...

Cały mój akapit brzmiał:
"[...] jeśli jest jakiś cel produktowy i osoba/osoby, które chcą
popychać produkt w kierunku realizacji tego celu, to czemu nie
skanalizować wysiłków korzystając z elementów Agile?"

Jeśli jest tak, że ktoś wie, czego się spodziewa po produkcie, a ja
w to wchodzę, to poniekąd zgadzam się z jego nadrzędną wobec mnie rolą.
Jeśli nie, to pewnie nie zainteresuję się tym projektem i wybiorę taki,
w którym można trochę "poszaleć" na własną rękę.

--
Paweł Kierski
n...@p...net

do góry

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

do góry

On 23/07/2013 07:13, Adam Klobukowski wrote:
> On Tuesday, 23 July 2013 02:16:02 UTC+2, Andrzej Jarzabek wrote:
>
> Yhm. Dla takiego trywialnego przypadku jest to proste.

Przykład był trywialny żeeby sensownie zilustrować tezę.

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

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.

do góry

On Tuesday, 23 July 2013 09:26:06 UTC+2, Andrzej Jarzabek wrote:
> On 23/07/2013 07:13, Adam Klobukowski wrote:
>
> > On Tuesday, 23 July 2013 02:16:02 UTC+2, Andrzej Jarzabek wrote:
> >
> > Yhm. Dla takiego trywialnego przypadku jest to proste.
>
> Przykład był trywialny żeeby sensownie zilustrować tezę.
>
> > 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ę.
>
> 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.

AdamK

do góry