Przypadki testowe pola tekstowego

Przeglądarka uznaje pole za wypełnione, a serwer za puste, albo odwrotnie.

Pole wygląda na puste, ale nie jest: walidacja pola wymaganego przechodzi, a rekord nie ma użytecznej nazwy.

Sortowanie stawia rekord na początku każdej listy, a wyszukiwanie dokładnego dopasowania nigdy go nie znajduje.

Przeglądarka i serwer różnie porównują login i adres e-mail. Konto zostaje założone, ale nie da się go znaleźć.

Klasyczna szerokość kolumny: jeden znak poniżej limitu, dokładnie na limicie i jeden ponad to trzy różne ścieżki w kodzie.

Jeden znak ponad klasyczny limit, czyli miejsce, w którym zwykle dochodzi do cichego obcięcia.

128 znaków, ale 256 bajtów: pole z limitem w bajtach odrzuca wartość, którą interfejs uznał za poprawną.

Limit najczęstszego typu kolumny tekstowej. Jego przekroczenie zwykle kończy się surowym błędem bazy danych.

Kodowanie węższe niż pełny zestaw znaków zamienia je na znaki zapytania i nazwisko psuje się przy zapisie.

Ta sama litera zapisana jako litera bazowa ze znakiem łączącym porównuje się jako różna od postaci jednoznakowej.

Znak spoza podstawowej płaszczyzny w polu imienia przekracza limity długości w bajtach i psuje bazy danych skonfigurowane na wąskie kodowania.

Znak wymuszający kierunek sprawia, że tekst wyświetla się odwrócony: użytkownik widzi inną wartość niż zapisana.

Serializatory i słabo typowane interfejsy zamieniają ten tekst na brak wartości. Pole wygląda na zapisane, a wraca puste.

YAML 1.1 i kilka parserów konfiguracji czyta słowo no bez cudzysłowu jako logiczne false - a NO to kod kraju Norwegii.

Parsery liczb je przyjmują, a potem każde porównanie z nim daje fałsz - filtry i sortowanie po cichu gubią wiersz.

Często jest skutkiem błędu gdzie indziej, więc prawdziwej wartości o tej pisowni nie da się odróżnić od usterki.

Pola ilości, ceny i liczby sztuk, które nigdy nie spodziewały się wartości ujemnej. Często ją przyjmują, a wychodzi to dopiero przy fakturowaniu.

Separator dziesiętny używany w większości Europy. Parsery oczekujące kropki czytają go jako separator tysięcy albo go odrzucają.

Jeden ponad najczęstszy limit liczb całkowitych - tu liczniki, identyfikatory i ilości przekręcają się na liczbę ujemną.

Powyżej tej wartości przeglądarki i wiele interfejsów przestaje dokładnie przedstawiać liczby całkowite, więc identyfikator zwrócony przez serwer nie zgadza się z tym, co widzi użytkownik.

Data, która nie może istnieć. Naiwne parsery przesuwają ją na drugiego marca, zamiast ją odrzucić.

Poprawna w jednych latach, a w innych nie, więc te same dane są poprawne albo błędne zależnie od pola roku obok.

Ten sam tekst oznacza marzec albo kwiecień zależnie od konwencji, a nic na ekranie nie mówi, którą przyjęto.

Lata pięciocyfrowe psują parsowanie o stałej szerokości i formaty kolumn, nie dając oczywistego błędu.

Wartość zaczynającą się od znaku równości arkusz kalkulacyjny traktuje jak formułę. Wyeksportowany plik pokazuje wynik obliczenia zamiast danych.

Przecinek w wartości dzieli jedną kolumnę na dwie, chyba że na każdym etapie eksportu wartość jest poprawnie ujęta w cudzysłów.

Kody tracą zera wiodące w chwili, gdy arkusz uzna kolumnę za liczbową.

Arkusze kalkulacyjne zachowują około piętnastu cyfr znaczących, więc długie identyfikatory wracają zaokrąglone i w zapisie wykładniczym.

Nazwa urządzenia zarezerwowana przez jeden z systemów operacyjnych. Pliku o tej nazwie nie da się utworzyć, a błąd często wychodzi jako ogólny komunikat.

Niektóre systemy plików po cichu usuwają kropki na końcu, więc zapisana nazwa różni się od żądanej.

Interfejsy, które ukrywają znane rozszerzenia, pokazują to jako report.txt, więc użytkownik widzi dokument, a dostaje program.

Dwie kropki to katalog nadrzędny - najkrótszy możliwy test wyjścia poza katalog (path traversal).