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