Chrono MockData, která stojí za testování
Software se nerozbije v obyčejné úterý. Rozbije se v poslední den čtvrtletí, 29. února, ve chvíli, kdy se mění rok, a o vteřinu po vypršení licence. Tohle jsou data, která takové chyby najdou - 14 z nich je dodáváno jako pojmenované scénáře.
Hranice období
Cokoli, co uzavírá období, čísluje doklad podle roku nebo připisuje do uzávěrky, se zde splete jako první.
- Poslední den měsíce - chová se správně měsíční uzávěrka a připisování za období v poslední den měsíce?
- Poslední den čtvrtletí - chová se správně čtvrtletní uzávěrka a výkaznictví v poslední den čtvrtletí?
- Poslední den fiskálního roku - uzavře aplikace fiskální rok ve správný den, den před začátkem fiskálního roku?
- Přechod roku za živa - zvládne číslování dokladů, rok v názvu a roční výkaznictví přechod roku přímo ve chvíli, kdy nastane, místo aby se po něm restartovaly?
Poslední z nich je ten, který lidé obvykle nemohou testovat vůbec, protože potřebuje, aby hodiny překročily půlnoc 31. prosince, zatímco aplikace běží. Se zrychlenými hodinami je to práce na deset vteřin.
Okraje kalendáře a reprezentace
- 29. února - přestupný den, který existuje jen jednou za čtyři roky a který překvapivé množství validačního kódu rovnou odmítne.
- Nula unixové epochy - bere aplikace 1. leden 1970 jako skutečné datum, nebo jako prázdnou hodnotu, kterou měla odmítnout uložit?
- Hranice roku 2038 - okamžik, kdy dojde 32bitový
time_tse znaménkem, v2038-01-19T03:14:07Z. O vteřinu později čítač přeteče do roku 1901.
Licence, zkušební doby a instalace
Slouží k testování vašeho vlastního licencování, což je případ, pro který vznikly.
- Poslední den zkušební doby - funguje aplikace ještě v úplně poslední okamžik zkušební doby?
- První den po vypršení zkušební doby - odepře přístup ve chvíli, kdy zkušební doba skončí, a jak? Rozumnou zprávou, nebo výpisem zásobníku?
- Licence vypršela před rokem - zvládne licenci, která vypršela dávno, ne jen včera?
- Datum před instalací - chová se správně, když jsou hodiny nastaveny před datum její vlastní instalace? Toto čte datum souboru samotného cíle, takže nepotřebuje žádný parametr.
Obchodní pravidla a chování hodin
- Splatnost platby, +N pracovních dnů - dopadne platba splatná za N pracovních dnů na správný den, s vynecháním víkendů a svátků správné země? Jediný scénář, který potřebuje kalendář, a odpověď se mezi trhy liší.
- Hranice zletilosti - pustí aplikace dovnitř někoho přesně na hranici a odmítne někoho, komu chybí jediný den?
- Odchylka hodin, +90 s - poradí si aplikace, když její hodiny jdou o devadesát vteřin před skutečným časem? To je případ, který rozbíjí jednorázová hesla založená na čase a ověřování tokenů.
Jak jeden použít
Scénář je pojmenovaný výraz pro datum. Kalkulačka vypočítá, co znamená, a náhrada času spustí aplikaci v něm - na obou místech stejný název.
# Jaké je to datum a co toto datum testuje? chrono calc --preset month-end # Spustit v něm aplikaci chrono run "C:\apps\test.exe" --preset year-rollover --report session.txt # Scénáře zkušební doby berou počáteční datum z data souboru samotného cíle chrono run "C:\apps\test.exe" --preset trial-first-day-after
V okně jsou to štítky nad polem pro datum - jedno kliknutí ho vyplní. Každý nese vlastní větu, která říká, co zachytí, což je část, kterou online kalkulačka dat nemá jak dát.
Co tu není
Přechody na letní a zimní čas. Protažení aplikace hranicí přechodu na letní nebo zimní čas je opravdu užitečný test a záměrně tu chybí, protože časové pásmo sezení je pevný posun bez letního času - zatím není co simulovat. Dodávat scénář, který by tiše nic nedělal, by bylo horší než ho nedodávat.
Vrátí se spolu s modelem pravidel časových pásem. Co časové pásmo dělá a co ne →