Guides · 3 min
Tests
Une commande qui pilote un vrai navigateur contre une vraie base, parce que les pannes qui comptent sont entre les pièces.
Les bugs qui atteignent les clients dans une application comme celle-ci ne sont presque jamais à l'intérieur d'une fonction. Ils sont entre deux fonctions : le cookie qui n'a pas survécu à la redirection, la policy qui laisse passer la mauvaise ligne, le panneau qui déborde à 360 pixels. Les tests unitaires n'en voient aucun.
La suite est donc un fichier unique qui se connecte pour de vrai, paie pour de vrai, et lit la page comme le ferait un client.
BASE=http://localhost:3000 node qa/buyer-flow.jsCe qu'elle fait
Crée un utilisateur via l'API admin
Puis le supprime d'abord s'il traîne depuis la dernière exécution, pour que la suite soit rejouable plutôt que verte une seule fois.
Se connecte avec un vrai lien magique
Généré exactement comme le construit le modèle d'e-mail : un token hash pointé sur votre propre callback. Si les modèles sont faux, ceci échoue, et c'est le but.
Accorde un droit comme le fait le webhook
Puis vérifie que le tableau de bord l'affiche : la clé, l'offre, le prix formaté dans la bonne devise.
Attaque ses propres policies
Lit chaque table avec la seule clé publiable et vérifie qu'elle n'obtient rien. Poste un webhook non signé et vérifie le 400.
Mesure le téléphone
Redimensionne à 360 de large et vérifie que scrollWidth ne dépasse jamais
clientWidth, sur chaque page, en nommant l'élément fautif quand c'est le cas.
Le contrôle de débordement
Celui-ci rapporte plus que tous les autres :
const over = await page.evaluate(() => {
const doc = document.documentElement;
return {
scrollW: doc.scrollWidth,
clientW: doc.clientWidth,
wide: [...document.querySelectorAll("body *")]
.filter((el) => el.getBoundingClientRect().right > doc.clientWidth + 1)
.slice(0, 3)
.map((el) => `${el.tagName}.${el.className}`),
};
});Il ne dit pas seulement que la page est trop large. Il nomme les trois éléments qui dépassent, ce qui transforme une chasse de vingt minutes en une correction d'une ligne.
Croire le test avant de croire le correctif
Quand un contrôle échoue, prouvez que le contrôle a raison avant de toucher au code. Une assertion qui échoue est une affirmation, pas un verdict, et la demi-heure passée à corriger un bug qui était en fait un mauvais sélecteur est une demi-heure perdue.
Ce qui n'est pas là
Il n'y a pas de tests unitaires, et c'est un choix plutôt qu'un oubli. Ajoutez-en là où vous avez de la vraie logique : arithmétique de prix, règles de droits d'accès, tout ce qui a des branches qu'il vaut la peine d'énumérer. N'en ajoutez pas pour vérifier qu'un composant s'affiche.
Une erreur ou un manque sur cette page ? Dites-le-nous.