On Wed, 21 Dec 2011 07:26:49 -0800 (PST), Maciej Sobczak
<s...@g...com> wrote:

>On Dec 21, 11:51 am, Roman W <b...@g...pl> wrote:
>> Na grupie padaly stwierdzenia, ze wymagania wobec programu mozna opisac w formie
testow.
>>
>> Zalozmy, ze mamy zaimplementowac funkcje (na przykladzie C++)
>>
>> double calculate_stuff(const std::vector<double>& data);
>>
>> z warunkiem "ma sie wykonywac w czasie liniowym w rozmiarze wektora data".
>>
>> Jak napisac test, ktory sprawdza czy ten wymog jest spelniony?
>
>Nie pisać.
>To jest jedna z tych rzeczy, którą łatwiej zrobić, niż sprawdzić
>(podobnie, jak wspomniany pogłos z filharmonii w Koluszkach).
>Pamiętajmy, że tworzenie testów też kosztuje, o czym zwolennicy TDD
>często zapominają.
>
>Przy okazji, powstaje również problem, jak sprawdzić, że test sprawdza
>to co miał sprawdzać? Bo koszt testów nie sprowadza się tylko do ich
>objętości, ale również do zrozumienia, jak zrobić test. Kto sprawdzi
>test?
>I w ogóle to dlaczego pisanie testów, których objętość może
>przekroczyć właściwy projekt (co TDDowcy przyznają) nie odbywa się
>według tej samej metody, która niby jest dobra do wszystkiego? Tzn.
>dlaczego testów nie pisze się według TDD? :-)
>
>Oprócz złożoności liniowej i pogłosu w filharmonii w Koluszkach,
>takich przykładów jest znacznie więcej. Np. mamy napisać generator
>liczb losowych o zadanym rozkładzie - jak to sprawdzić przez TDD?
>Tutaj również łatwiej jest to zrobić poprawnie przez właściwą
>konstrukcję, niż stworzyć poprawny test.
>
>Takich przykładów może być nieskończenie wiele, a to oznacza, że jest
>nieskończenie wiele projektów, dla których TDD jest niewłaściwym
>podejściem.
>Niespodzianka? Ani trochę.

TDD jest po to aby zapewnic zgodnosc kodu ze specyfikacja i po nic
wiecej

A.L.

do góry

On Wednesday, December 21, 2011 3:26:49 PM UTC, Maciej Sobczak wrote:

> Oprócz złożoności liniowej i pogłosu w filharmonii w Koluszkach,
> takich przykładów jest znacznie więcej. Np. mamy napisać generator
> liczb losowych o zadanym rozkładzie - jak to sprawdzić przez TDD?

To akurat robilem. Losowalem np. 10000 probem i sprawdzalem czy histogram sprawdza
sie w ramach zadanej tolerancji z zadana dystrybucja, oraz sprawdzalem momenty (jesli
istnialy). Nie jest to idealny test, ale lepszy rydz niz nic.

RW

do góry

Roman W <b...@g...pl> wrote:
> Na grupie padaly stwierdzenia, ze wymagania wobec programu mozna opisac w formie
testow.
>
> Zalozmy, ze mamy zaimplementowac funkcje (na przykladzie C++)
>
> double calculate_stuff(const std::vector<double>& data);
>
> z warunkiem "ma sie wykonywac w czasie liniowym w rozmiarze wektora data".
>
> Jak napisac test, ktory sprawdza czy ten wymog jest spelniony?
... w pythonie masz pakiet nose do testow z pluginem do pomiaru
czasu wykonania, podejrzewam, ze do C++ tez by sie cos takiego znalazlo. Z powazaniem
Adam Przybyla

do góry

On 12/21/2011 04:26 PM, Maciej Sobczak wrote:
> Oprócz złożoności liniowej i pogłosu w filharmonii w Koluszkach,
> takich przykładów jest znacznie więcej. Np. mamy napisać generator
> liczb losowych o zadanym rozkładzie - jak to sprawdzić przez TDD?
> Tutaj również łatwiej jest to zrobić poprawnie przez właściwą
> konstrukcję, niż stworzyć poprawny test.

Matematykiem to ja nie jestem, ale nawet ja wiem, że rozkład
będzie wykazywał jakiś średni rozrzut przy danych próbach. Ogólnie
temat random jest dobrze przerobiony, w tym testy randomów na potrzeby
kryptografii - są standardowe toole w Linuksie sprawdzające FIPS
ileśtam (nie wnikam, nie czytam, bo i tak nie zrozumiem w ciągu
godziny, a więcej czasu mi szkoda ;) ).

Istnieje wiele innych przykładów. Chociażby procesory. Są
projektowane, testowane, a potem wychodzi errata ze 100 bugami
średnio, bo zrobili dowody formalne czy coś innego. Przykład
moim zdaniem bardzo zbliżony do programowania.

Z samego programowania dowody (pół)formalne stosuje
się przy algorytmach wątkowych. Żaden unit test nie pokaże
błędu wielowątkowego, co najwyżej wysypie się np. raz na 1e4.
Jak wielu programistów robi, TDD: test, implementacja, przeszło
- czyli już zrobione.

Edek

do góry

On 2011-12-21 15:11, Roman W wrote:
> IMHO testowanie implementacji != dokumentacja wymagan i mieszanie tych rzeczy jest
bledem.

dokumentacja != implementacja. Jesli chcesz mieć pewnośc to i tak trzeba
testować. Ludzie omylni są.

do góry

On Dec 21, 5:18 pm, Roman W <b...@g...pl> wrote:

> > Oprócz złożoności liniowej i pogłosu w filharmonii w Koluszkach,
> > takich przykładów jest znacznie więcej. Np. mamy napisać generator
> > liczb losowych o zadanym rozkładzie - jak to sprawdzić przez TDD?
>
> To akurat robilem. Losowalem np. 10000 probem i sprawdzalem czy histogram sprawdza
sie w ramach zadanej tolerancji z zadana dystrybucja,

Jasne. Powiedzmy, że chodzi o liczby od 0 do 9 i rozkład jednostajny.

Oto mój generator:

int getNextValue()
{
static int x = 0;
if (x == 10) x = 0;
return x++;
}

Powyższa funkcja przy odpowiednio wielu wywołaniach daje całkiem dobry
"histogram".
Można tak zrobić dowolny zadany "rozkład" i go "przetestować" tak jak
opisałeś.

Jakoś jednak sądzę, że ta funkcja jest do bani. Ale test przeszła! To
może test jest do bani? Pewnie jest - ale jak sprawdzić ten test?

Łatwiej napisać generator liczb losowych, niż jego test.
To znaczy, że przy takim zadaniu w ogóle nie pisałbym unit-testu.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

On 21/12/2011 14:11, Roman W wrote:
> On Wednesday, December 21, 2011 2:07:09 PM UTC, Paweł Kierski wrote:
>> Na post-commit taki test się nie nadaje, ale w nocy masz z reguły kilka
>> godzin do dyspozycji. W skrajnym przypadku można tego rodzaju testy
>> zapuszczać tylko wtedy, kiedy to naprawdę niezbędne - np. przed
>> wdrażaniem wersji na produkcję. Pozostaje też kwestia różnic
>> w wydajności maszyn produkcyjnych i testowych/buildowych (jak ustawić
>> górne ograniczenie czasu wykonania testu).
>
> Do czego zmierzam: ze jezeli wymaganiem jest *formalna gwarancja* ze
> procedura implementuje algorytm wykonujacy sie w czasie liniowym, to
> zaden test tego adekwatnie nie dokumentuje. Tylko zwykla dokumentacja
> moze to, well, udokumentowac.

Trochę pół żartem, mogę powiedzieć, że można to testować jakimś testem typu:

void testProvedLinearComplexityOfCalculateStuff() {
fail(); // remove this line once proof is checked by customer
}

Trochę poważniej - jeśli klient wymaga formalnego dowodu złożoności
algorytmu, to prawdopodobnie możesz to obsłużyć poza metodologią
tworzenia oprogramowania - tam, gdzie masz proces do zapewnienia
odpowiednich 'deliverables'. Przecież nie sprawdzasz też automatycznymi
testami, czy została stworzona i dostarczona instrukcja dla użytkownika,
albo czy dział prawny sprawdził tekst licencji.

Natomiast samo wymaganie, żeby złożoność była liniowa, można bardzo
łatwo udokumentować testem, np. takim:

void testCalculateStuffComplexityIsLinear() {
assertThat(timeComplexityOf(claculate_stuff).is(line
ar()));
}

Wewnątrz implementacja oczywiście będzie robiła jakieś heurystyki, można
też sparametryzować ten test tak, żebyś miał prosty wariant który się
testuje z każdym buildem i wariant dla realnych zakresów użytkowania,
który się testuje przez noc, przez weekend albo nawet przez tydzień,
jeśli tego właśnie potrzebujesz.

do góry

On 21/12/2011 15:26, Maciej Sobczak wrote:
>
> Przy okazji, powstaje również problem, jak sprawdzić, że test sprawdza
> to co miał sprawdzać? Bo koszt testów nie sprowadza się tylko do ich
> objętości, ale również do zrozumienia, jak zrobić test. Kto sprawdzi
> test?

Oczywiście 100% gwarancji nie ma, ale wyobraź sobie, że o tym problemie
ktoś pomyślał. Przede wszystkim robienie testów przed napisaniem kodu
daje ci podstawowy test testu, mianowicie taki, że test nie przechodzi
kiedy tego, co testujesz jeszcze nie ma, a przechodzi, kiedy
funkcjonalność jest zaimplementowana. Druga sprawa jest taka, że do kodu
produkcyjnego stosuje się praktyki, które wymuszają sprawdzenie go przez
drugą osobę, i te same praktyki można stosować do testów - pair
programming albo code review. Acceptance tests pisze się dodatkowo razem
z OSCR-em i być może review-uje je product owner.

Z praktycznego punktu widzenia to nie jest jednak tak, że różnica jest
dopiero między programem z błędami, a programem, który w ogóle nie ma
żadnych błędów. Dużą różnicę robi ilość błędów, a przy TDD błąd trudniej
popełnić, bo oprócz tego, że trzeba zrobić błąd w kodzie, to jeszcze
trzeba zrobić błąd w teście, i to jeszcze musi być taki błąd, który
spowoduje, że błąd w kodzie nie zostanie wychwycony. O ile programista
ma dobre zrozumienie, co program ma robić, a ewentualne błędy
spowodowane są przez nieuwagę, to prawdopodobieństwa popełnienia tych
wszystkich błędów będzie zdecydowanie mniejsze, niż tylko tego w kodzie
programu.

> I w ogóle to dlaczego pisanie testów, których objętość może
> przekroczyć właściwy projekt (co TDDowcy przyznają) nie odbywa się
> według tej samej metody, która niby jest dobra do wszystkiego? Tzn.
> dlaczego testów nie pisze się według TDD? :-)

Bo testy to nie kod produkcyjny.

> Oprócz złożoności liniowej i pogłosu w filharmonii w Koluszkach,
> takich przykładów jest znacznie więcej. Np. mamy napisać generator
> liczb losowych o zadanym rozkładzie - jak to sprawdzić przez TDD?

Banalnie - zakładasz poziom pewności, np. 5 sigma i robisz skwantyzowany
soak test - generujesz liczby, wrzucasz w odpowiednie przedziały, jak
wygenerujesz odpowiednio dużo, to sprawdzasz, czy w każdym z przedziałów
jest odpowiednia ilość plus minus błąd. Jak ci się nie chce porządnie
liczyć błędów, to robisz "na oko" i ewentualnie korygujesz. Na tym
schemacie możesz zrobić unit test, który ci to sprawdza w pół sekundy, i
soak test, który leci godzinę.

do góry

On 21/12/2011 19:37, Edek wrote:
>
> Z samego programowania dowody (pół)formalne stosuje
> się przy algorytmach wątkowych. Żaden unit test nie pokaże
> błędu wielowątkowego, co najwyżej wysypie się np. raz na 1e4.

No więc jeśli wiesz, że błędna implementacja wysypie się raz na 1e4, to
jeśli zrobiłeś test, który odpala się 1e6 razy, to masz znacznie lepszą
gwarancję poprawności, niż gdybyś tylko zrobił dowód (pół)formalny.

> Jak wielu programistów robi, TDD: test, implementacja, przeszło
> - czyli już zrobione.

Nie wiem, ale inteligentni programiści z jakimkolwiek doświadczeniem,
lub choćby tacy, którzy czytali o tym książkę, wiedzą o
obszarach-pułapkach, jakimi są np. wątki, i w związku z tym wiedzą, że
trzeba zrobić coś więcej. A jak sami nie wiedzą co, to mogą spytać
bardziej doświadczonych kolegów, albo chociażby przeczytać o tym
książkę. Freeman i Pryce mają np. bardzo sensowny rozdział o testowaniu
programów wielowątkowych w TDD.

do góry

On 21/12/2011 23:13, Maciej Sobczak wrote:
>
> Jakoś jednak sądzę, że ta funkcja jest do bani. Ale test przeszła! To
> może test jest do bani? Pewnie jest - ale jak sprawdzić ten test?

Daje rozkład jednostajny. Nie daje liczb losowych, ale funkcji, która
daje liczby losowe nie ma.

> Łatwiej napisać generator liczb losowych, niż jego test.
> To znaczy, że przy takim zadaniu w ogóle nie pisałbym unit-testu.

Testy to nie tylko unit testy.

Natomiast tak w ogóle w wielu przypadkach dla funkcji pseudo-losowej
łatwo napisać unit test. Powiedzmy, że funkcja korzysta z algorytmu X,
który wziąłeś z literatury, lub też w inny sposób stwierdziłeś, że jest
wystarczająco "losowy". Bierzesz referencyjną implementację algorytmu,
napisaną przez kogoś innego bądź sam piszesz, i rejestrujesz pierwszą
zwróconą liczbę dla jakiejś puli przypadkowo wybranych seed-ów. Możesz
też zarejestrować setną zwróconą liczbę albo tysięczną, albo
stutysięczną (w zależności jak długo algorytm działa). Zapisujesz te
dane w teście et voila, masz test sprawdzający, czy funkcja dalej
korzysta z algorytmu X. Jeśli korzysta, to znaczy, że jest wystarczająco
"losowa" według przyjętych przez ciebie kryteriów. Jeśli nie, to badamy
o co kaman i albo naprawiamy funkcję, albo zmieniamy test.

do góry