Les dates qui valent la peine d'être testées

Tout ce qui clôt une période, numérote un document par année ou cumule jusqu'à une date butoir se trompe ici en premier.

• Dernier jour du mois - la clôture mensuelle et les écritures de rattachement se comportent-elles bien le dernier jour du mois ?
• Dernier jour du trimestre - la clôture trimestrielle et le reporting se comportent-ils bien le dernier jour du trimestre ?
• Dernier jour de l'exercice fiscal - l'application clôt-elle l'exercice le bon jour, la veille du début de l'exercice suivant ?
• Passage d'année, en direct - la numérotation des documents, l'année dans le nom et le reporting annuel gèrent-ils le basculement pendant qu'il se produit, plutôt que d'être redémarrés après coup ?

Le dernier est celui que l'on ne peut généralement pas tester du tout, car il faut que l'horloge franchisse minuit le 31 décembre pendant que l'application tourne. C'est l'affaire de dix secondes avec une horloge accélérée.

• 29 février - le jour bissextile qui n'existe que tous les quatre ans et que bien du code de validation rejette purement et simplement.
• Epoch Unix zéro - l'application traite-t-elle le 1er janvier 1970 comme une vraie date, ou comme une valeur vide qu'elle aurait dû refuser de stocker ?
• Limite de 2038 - le moment où un time_t signé de 32 bits est épuisé, à 2038-01-19T03:14:07Z. Une seconde plus tard, le compteur déborde jusqu'en 1901.

Ceux-ci servent à tester votre propre gestion des licences, ce pour quoi ils ont été écrits.

• Dernier jour d'essai - l'application fonctionne-t-elle encore à tout dernier moment de l'essai ?
• Premier jour après l'expiration de l'essai - refuse-t-elle l'accès à l'instant où l'essai se termine, et comment ? Un message sensé, ou une trace de pile ?
• Licence expirée il y a un an - gère-t-elle une licence expirée depuis longtemps, et pas seulement depuis hier ?
• Date antérieure à l'installation - se comporte-t-elle bien quand l'horloge est réglée avant sa propre date d'installation ? Celui-ci lit la date du fichier de la cible elle-même, il n'a donc besoin d'aucun paramètre.

• Paiement dû, +N jours ouvrés - un paiement dû dans N jours ouvrés tombe-t-il le bon jour, en sautant les week-ends et les jours fériés du bon pays ? Le seul scénario qui exige un calendrier, et la réponse diffère d'un marché à l'autre.
• Limite de la majorité - l'application admet-elle quelqu'un exactement à la limite, et refuse-t-elle quelqu'un à un jour près ?
• Dérive d'horloge, +90 s - l'application s'en sort-elle quand son horloge avance de quatre-vingt-dix secondes sur le temps réel ? C'est le cas qui casse les mots de passe à usage unique basés sur le temps et la validation des jetons.

Un scénario est une expression de date nommée. Le calculateur détermine ce qu'elle signifie, et la substitution exécute une application à cette date - le même nom aux deux endroits.

Dans la fenêtre, ce sont des pastilles au-dessus du champ de date - un clic le remplit. Chacune porte sa propre phrase qui dit ce qu'elle détecte, ce qu'un calculateur de dates en ligne ne peut pas vous donner.

Les changements d'heure d'été. Faire traverser à une application la limite du passage à l'heure d'été ou du retour à l'heure d'hiver est un test réellement utile, et il est volontairement absent, car le fuseau horaire de la session est un décalage fixe sans heure d'été - il n'y a pas encore de transition à simuler. Livrer un scénario qui ne ferait discrètement rien serait pire que de ne pas le livrer.

Il reviendra avec un modèle des règles de fuseau horaire. Ce que le fuseau horaire fait et ne fait pas →