Date care merită testate

Orice închide o perioadă, numerotează un document după an sau acumulează până la o dată-limită greșește primul aici.

• Ultima zi a lunii - se comportă corect închiderea de lună și acumularea pe perioadă în ultima zi a lunii?
• Ultima zi a trimestrului - se comportă corect închiderea de trimestru și raportarea în ultima zi a trimestrului?
• Ultima zi a anului fiscal - închide aplicația anul fiscal în ziua potrivită, ziua dinaintea începerii anului fiscal?
• Schimbarea anului, în direct - tratează numerotarea documentelor, anul din nume și raportarea anuală trecerea în anul nou în timp ce se petrece, în loc să fie repornite după aceea?

Ultimul este cel pe care oamenii de obicei nu pot să-l testeze deloc, pentru că are nevoie ca ceasul să treacă de miezul nopții de 31 decembrie în timp ce aplicația rulează. Cu un ceas accelerat, e treaba a zece secunde.

• 29 februarie - ziua bisectă care există doar o dată la patru ani și pe care o cantitate surprinzătoare de cod de validare o respinge pur și simplu.
• Epoch Unix zero - tratează aplicația 1 ianuarie 1970 ca pe o dată reală sau ca pe o valoare goală pe care ar fi trebuit să refuze să o stocheze?
• Limita 2038 - momentul în care se epuizează un time_t pe 32 de biți cu semn, la 2038-01-19T03:14:07Z. O secundă mai târziu, contorul trece peste limită și ajunge în 1901.

Acestea sunt pentru testarea propriului tău mecanism de licențiere, cazul pentru care au fost scrise.

• Ultima zi de probă - mai funcționează aplicația în chiar ultima clipă a probei?
• Prima zi după expirarea probei - refuză accesul în clipa în care se încheie proba și cum? Un mesaj rezonabil sau un stack trace?
• Licență expirată acum un an - tratează o licență expirată demult, nu doar de ieri?
• Data dinaintea instalării - se comportă corect când ceasul este setat înainte de propria dată de instalare? Aceasta citește data fișierului țintei, deci nu are nevoie de niciun parametru.

• Plată scadentă, +N zile lucrătoare - o plată scadentă peste N zile lucrătoare ajunge în ziua corectă, sărind weekendurile și sărbătorile țării potrivite? Singurul scenariu care are nevoie de un calendar, iar răspunsul diferă între piețe.
• Limita majoratului - admite aplicația pe cineva exact la limită și refuză pe cineva căruia îi lipsește o zi?
• Decalaj de ceas, +90 s - se descurcă aplicația când ceasul ei merge cu nouăzeci de secunde înaintea timpului real? Este cazul care strică parolele unice bazate pe timp și validarea token-urilor.

Un scenariu este o expresie de dată cu nume. Calculatorul stabilește ce înseamnă, iar înlocuirea rulează o aplicație la ea - același nume în ambele locuri.

În fereastră sunt chip-uri deasupra câmpului de dată - un clic îl completează. Fiecare poartă propria propoziție care spune ce prinde, parte pe care un calculator de date online nu are cum să ți-o dea.

Tranzițiile ora de vară / ora de iarnă. Trecerea unei aplicații prin limita de trecere la ora de vară sau de iarnă este un test cu adevărat util și lipsește în mod deliberat, pentru că fusul orar al sesiunii este un decalaj fix, fără ora de vară - nu există încă nicio tranziție de simulat. Un scenariu care nu ar face nimic pe tăcute ar fi mai rău decât unul nelivrat.

Revine odată cu un model al regulilor de fus orar. Ce face și ce nu face fusul orar →