FR EN

Chapitre 18Exploiter

Contrôles et tests

Quatre contrôles qui bloquent la branche, une suite de tests qui appelle les routes pour de vrai. Ce que chacun attrape, et pourquoi il existe.

5 min de lecture11 sectionsChapitre 18 / 22

Deux commandes

bash bash 
npm run check    # quatre contrôles sur le site construit
npm test         # la suite complète, qui construit au passage

Ce sont exactement celles que lance l'intégration continue, et elles bloquent la branche. Un contrôle qui ne bloque pas se contourne, puis se désactive, puis disparaît.

Les quatre contrôles

check-html — le contenu est-il dans le HTML brut ?

C'est le filet du projet. Il vérifie trois choses sur le HTML réellement construit :

  1. chaque valeur texte du JSON est présente dans la source HTML ;
  2. chaque data-cms du HTML pointe vers une clé qui existe dans le JSON ;
  3. aucune zone éditable ne se trouve à l'intérieur d'une île hydratée.
ContrôleCe qu'il attrape
1client:only — le contenu n'est dans aucun HTML servi, donc dans aucun index.
2Un chemin obsolète après un renommage de clé.
3client:load autour d'une zone éditable — le framework la réaffiche au chargement et efface les modifications en cours du client. Invisible dans la source.
Une liste à tenir à jour

Le script énumère explicitement les pages à vérifier, une entrée par page et par langue. Ajouter une page ou une langue sans compléter cette liste laisse un contrôle qui passe sans rien vérifier.

scripts/check-html.mjs js 
const PAGES = [
  { content: 'src/content/pages/fr/home.json', html: 'dist/fr/index.html' },
  { content: 'src/content/pages/en/home.json', html: 'dist/en/index.html' },
];

check-locales — les langues disent-elles la même chose ?

Échoue sur toute clé présente dans une langue et absente d'une autre, dans les deux sens : une clé traduite qui n'existe pas dans la langue de référence ne serait jamais affichée, et c'est un travail perdu qu'il vaut mieux voir tout de suite.

check-logs — un secret peut-il fuir par un journal ?

Refuse un console.* qui évaluerait un jeton, une empreinte, un cookie, une session, ou un objet qui les contient (env, headers, payload).

Accepté

js js 
console.error('[save] écriture impossible (clé absente)');
console.warn('[auth] débit dépassé');

Les chaînes sont retirées avant l'analyse : un message en français parlant de « clé » n'est pas une fuite.

Refusé

js js 
console.error(key);
console.log(env);
console.error(error);   // peut contenir une réponse d'API

C'est la ligne qu'on ajoute six mois plus tard pour déboguer, et qu'on oublie de retirer.

check-secrets — le build contient-il un secret ?

Inspecte le dossier de build à la recherche d'empreintes, de jetons et de motifs de secret. Il ne remplace pas la règle « aucun secret dans le dépôt » : il vérifie qu'aucun accident ne l'a contournée — une variable de build exposée, une valeur recopiée dans un composant.

La suite de tests

CommandeCe qui est éprouvé
npm run test:gitLe fournisseur Git : lecture, écriture, conflit, traduction des erreurs. Hors ligne par défaut, réel avec --online.
npm run test:authEmpreinte, comparaison en temps constant, signature et durée de session, cookies.
npm run test:guardDébit, plafonds, chemins, et l'ordre des contrôles — en appelant les routes directement.
npm run test:sanitizeLe même corpus soumis aux deux assainisseurs — navigateur et serveur — et comparé.
npm run test:mediaReconnaissance des formats aux octets, lecture des dimensions, réécriture des noms.
npm run test:heicReconnaissance du HEIC ; le décodage est sauté faute d'échantillon, sauf si INLINE_HEIC_SAMPLE est fourni.
npm run test:bootstrapL'amorçage sur une page annotée versionnée, y compris ses refus.
npm run test:localesLe repli de traduction et le marquage des champs non traduits.
npm run test:editorLa logique de l'overlay : résolution des chemins, réconciliation des items, brouillon.
npm run test:scaffoldUn site créé de zéro, installé, construit, contrôlé.
Pourquoi test:guard appelle les routes

Un plafond de taille placé après la lecture du corps ne protège de rien, et une vérification d'identité placée avant le comptage de débit laisse marteler la route. Tester les règles isolément ne dit rien de leur ordre : c'est pour cela que ce test passe par les routes réelles.

Éprouver ce qui partirait au registre

Deux commandes qui ne répondent pas à la même question.

npm run test:scaffold

Est-ce que le code marche ? Crée un site, installe le paquet par son chemin dans le dépôt, construit, contrôle.

npm run test:pack

Est-ce que ce qui partirait au registre marche ? Même chose, mais en passant par npm pack : les archives exactes qu'une publication produirait.

Le second est le seul mode qui attrape un fichier oublié dans files ou un chemin absent d'exports — des erreurs invisibles tant qu'on installe depuis un dossier, et qui cassent le premier site d'un tiers. À lancer avant toute publication.

Dans l'intégration continue

Le workflow livré lance npm test puis npm run check, sur chaque poussée et chaque proposition de fusion. Aucun secret n'y est nécessaire : les contrôles ne touchent ni au dépôt de contenu ni au jeton d'écriture — ils construisent le site et l'inspectent.

Le dépôt de référence ajoute un second travail, séparé parce qu'il installe un projet neuf et prend quelques minutes : sans lui, le modèle embarqué par create-inline diverge en silence du dépôt de référence, et on ne s'en aperçoit qu'au prochain client.

Ajouter un contrôle

Un contrôle utile a trois propriétés :

  1. il bloque — sinon il ne sert qu'à donner bonne conscience ;
  2. il porte sur le résultat, pas sur l'intention : le HTML construit, le dossier de build, la réponse d'une route ;
  3. il échoue avec un message qui dit quoi faire, pas seulement ce qui ne va pas.

Un contrôle propre au site va dans scripts/ et s'ajoute à check. Un contrôle qui serait vrai chez tous les clients va dans le paquet — et devient une évolution versionnée.

Avant chaque commit

bash bash 
npm test && npm run check

Deux minutes. C'est le prix d'un correctif trouvé avant la fusion plutôt qu'après la mise en ligne chez un client.