Jako osoba, która popełniła ten artykuł czuję się wywołany do tablicy.
mcoder napisał(a)
Czy to czasem nie sugeruje, że programy mają być odporne na "idiotów" i programista musi przewidzieć wszystko?
Nie chodzi tu o idiotoodporność, ale przede wszystkim o zapewnienie prawidłowej implementacji. Testy prowadzone manualnie mają przede wszystkim za zadanie wykryć problemy które mogą się "urodzić" poprzez nieuwagę użytkownika. Kolejnym problemem jest poszukiwanie potencjalnych podatności na niezbyt wyszukane ataki code injection/remote code invocation.
Artykuł traktuje jednak o testach jednostkowych, czyli tych prowadzonych przez programistów w trakcie pisania kodu. One mają zupełnie inne zadanie! Po pierwsze pozwalają sprawdzić czy to co napisałeś jest poprawne - czy dla zbioru prawidłowych wartości wejściowych otrzymujemy poprawne wyjście. Po drugie pozwalają na wykrywanie błędów - dlaczego dla konkretnych wartości program się sypie. Po trzecie określają jak powinien zachowywać się program w warunkach brzegowych - co będzie gdy podasz 9.999, a nie 9.99 itp. Po czwarte testy jednostkowe są zazwyczaj najlepszą dokumentacją (o ile są poprawnie napisane), ponieważ pokazują na przykładach JAK należy używać danego API.
Walidatory są bardzo wdzięcznym tematem testów. Między innymi dlatego, że poza prostymi przypadkami, same litery, same cyfry, liczba z dwoma cyframi po przecinku itp, masz całe multum przypadków znacznie bardziej skomplikowanych np. PESEL, IBAN, walidacje warunkowe na wielu polach obiektu, walidacje zależne od stanu całej aplikacji.
W sumie należało by wrócić do pisania na 4p... tylko czasu brak ;)