Na forum 4programmers.net korzystamy z plików cookies. Część z nich jest niezbędna do funkcjonowania
naszego forum, natomiast wykorzystanie pozostałych zależy od Twojej dobrowolnej zgody, którą możesz
wyrazić poniżej. Klikając „Zaakceptuj Wszystkie” zgadzasz się na wykorzystywanie przez nas plików cookies
analitycznych oraz reklamowych, jeżeli nie chcesz udzielić nam swojej zgody kliknij „Tylko niezbędne”.
Możesz także wyrazić swoją zgodę odrębnie dla plików cookies analitycznych lub reklamowych. W tym celu
ustaw odpowiednio pola wyboru i kliknij „Zaakceptuj Zaznaczone”. Więcej informacji o technologii cookie
znajduje się w naszej polityce prywatności.
Czy to czasem nie sugeruje, że programy mają być odporne na "idiotów" i programista musi przewidzieć wszystko?
Czy jak jest pole Cena to mam blokować wpisywanie liter, blokować przecinek, bo program oddziela części dziesiętne przez kropkę a nie przecinek, sprawdzać czy nie ma dwóch minusów i na dodatek sprawdzać czy wartość nie jest czasem za długa?
Gdy użytkownik wpisze złe dane i program "się wykrzaczy" to jest to wina programisty? Ja myślę, że użytkownika - niech myśli co wpisuje, jak to jest cena to nie wpisuje się 0-1-.2,a tylko 9.99 itp.
Ja jako użytkownik oczekuję, że w pole cena nie będę mógł wpisać niczego, co ceną nie jest. Jeśli mogę tam wpisać cokolwiek, to program jest nieintuicyjny i nieprzyjazny użytkownikowi, a autor jest słaby.
A jest automat na którym jest napisane "Automat przyjmuje monety 5, 2, 1 zł", czyli oczekujesz komunikatu "Zły nominał" i zwrócenia pieniędzy, gdy wrzucisz tam 10zł papierowe?
Ja myślę, że tak samo mogę to rozwiązywać w programach robiąc nad textboxem taki label:
"Cena (np. 9.99, pamiętaj o kropce):"
Sorry, ale wymaganie kropki tam, gdzie powinien być przecinek, też jest programistycznym lamerstwem. Nie wiem, czy nie gorszym niż brak walidacji.
Twój przykład jest też z czapy. Walidacja danych wejściowych w automacie polega na tym, że napój jest wydawany po wrzuceniu prawdziwych monet, a nie np. kawałka blachy.
Hmmm, Testy są bardzo ważnym aspektem i nie myśł ze po unit testach będzie już koniec testów, po tym dopiero zaczna się testy modułowe, mockowanie poszczególnych funkcji, oraz testy systemowe danej aplikacji. A wykonuje się, by sprawdzić czy aplikacja nie zawiera błędow, w ilu procentach jest ona pokrywa z wymaganiami i tak dalej można wyliczać. Jeżeli będziesz miał zrobiona aplikacje a chcesz troszkę zaoszczedzić czasu, to robisz testy automatyczne(w php np. Selenium).
Usunąć wpis?
Tej operacji nie będzie można cofnąć.
cw
cw
0
problem robi się jeszcze bardziej skomplikowany w aplikacjach webowych bo w zależności od ustawień regionalnych do oddzielania części dziesiętnym może być używany przecinek lub kropka. Nie sprawdzając tego można doprowadzić np. do sytuacji, że użytkownik wpisując 10,44 zapisze w bazie 10. Ogólnie uznaję zasadę, że nie można "wierzyć" użytkownikowi i dlatego program musi zabezpieczony przed wpisywaniem "głupot".
Miałam kiedyś taki przypadek, że trzeba było wypełnić ALBO jedno pole, ALBO 3 kolejne. Jako że walidacja w całym programie polegała po prostu na wyświetleniu komunikatów (i pozostawienie poprawki użytkownikowi), tak samo zrobiłam tu - na czerwono wielki napis: ALBO - ALBO. Dostałam naście zgłoszeń, że jest błąd, i wysyłają mi ludzie screeny, na których mają wypełnione WSZYSTKIE pola, i nad każdym z nich wielki czerwony komunikat.... Odpisałam ludziom coś w stylu "czytajcie komunikaty". W następnym tygodniu dostałam kolejne naście zgłoszeń "błędu"... również od tych samych ludzi... Mogłam się tak użerać do dziś, zamiast tego dorobiłam małą funkcję w javascripcie, która nie pozwala na wypełnienie niepotrzebnych pól. Niestety, trzeba założyć, że użytkownik jest nie tylko głupi, nie będzie również czytał komunikatów.
Inna sytuacja - dziewczyna zgłasza zadanie, że chociaż robi wszystko jak zawsze, nagle nie działa. Przychodzę do niej do komputera i proszę, by pokazała co robi. Wpisuje ona dane do formatki, klika OK, pojawia się jakiś komunikat błędu (po ikonce poznałam), na którym ona szybciutko kliknęła OK i z triumfem pokazuje, że w tekście się nic nie pojawiło...
Ten komunikat błędu to było coś w stylu: "Nie można wstawić, bo nie ma dostępu do Internetu". Akurat było 2godzinne wyłączenie sieci w firmie...
Szybkie zamykanie komunikatów błędów i pytanie "dlaczego nie działa" to standard. Próbuję tego oduczyć mojej rodzicielki. Zawsze przez telefon: - coś tu wyskoczyło i nie działa - co wyskoczyło, przeczytaj - "bla bla", aaa! no tak, dzięki
Do mnie zadzwoniła kobita, że komputer się nie uruchamia i piszczy. Przyszedłem, spojrzałem, przełożyłem książkę naciskającą klawisz enter na numerycznej i wyszedłem.
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 ;)
problem robi się jeszcze bardziej skomplikowany w aplikacjach webowych bo w zależności od ustawień regionalnych do oddzielania części dziesiętnym może być używany przecinek lub kropka.
To mnie boli w kalkulatorze Google:
3.3 + 5.5 => 8.8
3,3 + 5,5 => 8.8
3,3 + 5.5 => <kalkulator się nie aktywuje>
A często przeklejam różne wartości z różnych źródeł i muszę ręcznie poprawiać na jeden standard
