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?

RW

do góry

W dniu 2011-12-21 11:51, Roman W pisze:
> 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?

Mierzysz czas dla dwóch-trzech wielkości wektora i sprawdzasz
(asercją), czy czasy spełniają warunek liniowości. Np. test dla 10
i 1000 elementów - jeśli test dla 1000 wykonuje się ok 100 razy dłużej
niż dla 10, to OK. Jeśli 10000 razy dłużej, to masz n^2. Do tego
niektóre frameworki mają możliwość ograniczeń czasowych na testy -
pomocne, gdy implementacja jest jednak n^2 i miałaby się zakończyć
za kwadrans, zamiast za kilkanaście sekund. Timeout na minutę oznacza,
że coś na pewno jest źle.

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

do góry

On Wednesday, December 21, 2011 11:37:22 AM UTC, Paweł Kierski wrote:
> Mierzysz czas dla dwóch-trzech wielkości wektora i sprawdzasz
> (asercją), czy czasy spełniają warunek liniowości. Np. test dla 10
> i 1000 elementów - jeśli test dla 1000 wykonuje się ok 100 razy dłużej
> niż dla 10, to OK. Jeśli 10000 razy dłużej, to masz n^2. Do tego

Co jezeli uzyty algorytm jest mniej-wiecej liniowy dla N <= 1000, ale kwadratowy dla
N > 2000?

RW

do góry

W dniu 2011-12-21 13:05, Roman W pisze:
> On Wednesday, December 21, 2011 11:37:22 AM UTC, Paweł Kierski wrote:
>> Mierzysz czas dla dwóch-trzech wielkości wektora i sprawdzasz
>> (asercją), czy czasy spełniają warunek liniowości. Np. test dla 10
>> i 1000 elementów - jeśli test dla 1000 wykonuje się ok 100 razy dłużej
>> niż dla 10, to OK. Jeśli 10000 razy dłużej, to masz n^2. Do tego
>
> Co jezeli uzyty algorytm jest mniej-wiecej liniowy dla N<= 1000, ale kwadratowy dla
N> 2000?

Sprawdzać dla wartości, dla jakich się spodziewasz i dla jakich
liniowość ma dla Ciebie znaczenie.

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

do góry

On Wednesday, December 21, 2011 12:14:13 PM UTC, Paweł Kierski wrote:
> Sprawdzać dla wartości, dla jakich się spodziewasz i dla jakich
> liniowość ma dla Ciebie znaczenie.

Zalozmy, ze spodziewam sie ze w produkcji N = 10^6 i test wtedy bedzie sie wykonywal
godzine. Czy wtedy dokumentacja wymagan w postaci testu tez jest dobrym rozwiazaniem?

RW

do góry

W dniu 2011-12-21 14:29, Roman W pisze:
> On Wednesday, December 21, 2011 12:14:13 PM UTC, Paweł Kierski wrote:
>> Sprawdzać dla wartości, dla jakich się spodziewasz i dla jakich
>> liniowość ma dla Ciebie znaczenie.
>
> Zalozmy, ze spodziewam sie ze w produkcji N = 10^6 i test wtedy bedzie sie
wykonywal godzine. Czy wtedy dokumentacja wymagan w postaci testu tez jest dobrym
rozwiazaniem?

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

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

do góry

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.

IMHO testowanie implementacji != dokumentacja wymagan i mieszanie tych rzeczy jest
bledem.

RW

do góry

On Wed, 21 Dec 2011 12:37:22 +0100, Pawe? Kierski <n...@p...net>
wrote:

>W dniu 2011-12-21 11:51, Roman W pisze:
>> 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?
>
>Mierzysz czas dla dwóch-trzech wielkości wektora i sprawdzasz
>(asercją), czy czasy spełniają warunek liniowości. Np. test dla 10
>i 1000 elementów - jeśli test dla 1000 wykonuje się ok 100 razy dłużej
>niż dla 10, to OK. Jeśli 10000 razy dłużej, to masz n^2. Do tego
>niektóre frameworki mają możliwość ograniczeń czasowych na testy -
>pomocne, gdy implementacja jest jednak n^2 i miałaby się zakończyć
>za kwadrans, zamiast za kilkanaście sekund. Timeout na minutę oznacza,
>że coś na pewno jest źle.

Echem... Akurat... Metoda Simplex jak wiadomo ma zlozonosc
wykladnicza, a wszystkie testy pokazuja ze wielomianowa. Zeby dostac
naprawde zlozonosc wykladnicza tzreba skonstruowac specjalny prtzyklad
co nastapilo cos w 30 lat po sformulowaniu metody.

Niestety, zlozonosci nei da sie testowac "na przykaldach" a "test
driven development" wymyslono po cos supelnie innego

A.L.

do góry

On Wednesday, December 21, 2011 2:27:31 PM UTC, A. L. wrote:
> Echem... Akurat... Metoda Simplex jak wiadomo ma zlozonosc
> wykladnicza, a wszystkie testy pokazuja ze wielomianowa. Zeby dostac
> naprawde zlozonosc wykladnicza tzreba skonstruowac specjalny prtzyklad
> co nastapilo cos w 30 lat po sformulowaniu metody.

Dla skonczonej liczby punktow funkcje wykladnicza zawsze da sie dofitowac
wielomianem, wiec takie testy moga byc tylko i wylacznie heurystyczne.

RW

do góry

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

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

do góry