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.