Chrono MockDaty warte testowania
Oprogramowanie nie psuje się w zwykłe wtorki. Psuje się ostatniego dnia kwartału, 29 lutego, w chwili przełomu roku i sekundę po wygaśnięciu licencji. To są daty, które znajdują takie błędy - 14 z nich jest dostarczanych jako nazwane scenariusze.
Granice okresów
Cokolwiek zamyka okres, numeruje dokument rokiem albo nalicza do daty granicznej, myli się na nich w pierwszej kolejności.
- Ostatni dzień miesiąca - czy zamknięcie miesiąca i naliczenia okresowe zachowują się poprawnie ostatniego dnia miesiąca?
- Ostatni dzień kwartału - czy zamknięcie kwartału i raportowanie zachowują się poprawnie ostatniego dnia kwartału?
- Ostatni dzień roku obrotowego - czy aplikacja zamyka rok obrotowy właściwego dnia, czyli w dniu poprzedzającym start nowego?
- Przełom roku, na żywo - czy numeracja dokumentów, rok w nazwie i raporty roczne radzą sobie z przełomem w trakcie, a nie dopiero po restarcie?
Tego ostatniego zwykle nie da się przetestować w ogóle, bo wymaga, żeby zegar przeszedł przez północ 31 grudnia w czasie działania aplikacji. Z przyspieszonym zegarem to robota na dziesięć sekund.
Krawędzie kalendarza i reprezentacji
- 29 lutego - dzień przestępny, który istnieje tylko co cztery lata i który zaskakująco dużo kodu walidującego odrzuca wprost.
- Zero epoki uniksowej - czy aplikacja traktuje 1 stycznia 1970 jako prawdziwą datę, czy jako pustą wartość, której nie powinna była zapisać?
- Granica 2038 - chwila, w której kończy się 32-bitowy
time_tze znakiem, czyli2038-01-19T03:14:07Z. Sekundę później licznik przepełnia się w rok 1901.
Licencje, wersje próbne i instalacja
Te są do testowania własnego licencjonowania i dokładnie po to powstały.
- Ostatni dzień wersji próbnej - czy aplikacja nadal działa w ostatniej chwili jej trwania?
- Pierwszy dzień po wygaśnięciu - czy odmawia dostępu dokładnie w momencie końca i w jaki sposób? Sensownym komunikatem czy zrzutem stosu?
- Licencja wygasła rok temu - czy radzi sobie z licencją, która wygasła dawno, a nie wczoraj?
- Data sprzed instalacji - czy zachowuje się poprawnie, gdy zegar jest ustawiony przed jej własną datą instalacji? Ten scenariusz czyta datę pliku celu, więc nie potrzebuje parametru.
Reguły biznesowe i zachowanie zegara
- Płatność za N dni roboczych - czy płatność wymagalna za N dni roboczych ląduje we właściwym dniu, pomijając weekendy i święta właściwego kraju? To jedyny scenariusz wymagający kalendarza, a odpowiedź różni się między rynkami.
- Granica pełnoletności - czy aplikacja wpuszcza kogoś dokładnie na granicy i odmawia komuś, komu brakuje jednego dnia?
- Dryf zegara, +90 s - czy aplikacja radzi sobie, gdy jej zegar wyprzedza prawdziwy o dziewięćdziesiąt sekund? To przypadek psujący hasła jednorazowe oparte na czasie i walidację tokenów.
Jak użyć
Scenariusz to nazwane wyrażenie daty. Kalkulator wylicza, co ono znaczy, a podmiana uruchamia w nim aplikację - ta sama nazwa w obu miejscach.
# Jaka to data i co ta data testuje? chrono calc --preset month-end # Uruchom w niej aplikację chrono run "C:\apps\test.exe" --preset year-rollover --report session.txt # Scenariusze wersji próbnej biorą datę startu z daty pliku celu chrono run "C:\apps\test.exe" --preset trial-first-day-after
W oknie są to przyciski nad polem daty - jedno kliknięcie je wypełnia. Każdy niesie własne zdanie mówiące, co wyłapuje, czyli część, której kalkulator dat online nie ma jak ci dać.
Czego tu nie ma
Zmian czasu na letni i zimowy. Przeprowadzenie aplikacji przez taką granicę jest naprawdę użytecznym testem i jest celowo nieobecne, bo strefa czasowa sesji to stały offset bez czasu letniego - nie ma jeszcze przejścia do zasymulowania. Dostarczenie scenariusza, który po cichu nic by nie robił, byłoby gorsze niż niedostarczenie go.
Wróci razem z modelem reguł stref czasowych. Co strefa robi, a czego nie →