k6-script-creation

Que fait k6-script-creation ?

Cette skill génère des tests de performance avec k6 que chaque membre de l’équipe peut exécuter, comprendre et corriger, même sans connaître k6. Pour cela, chaque script est structuré de manière identique, avec des noms explicites, des credentials hors du code et un fichier .md qui l’explique étape par étape.

Priorités de l’équipe : load et stress, aussi bien HTTP que k6 browser. Le smoke est toujours une étape préalable obligatoire.

Source de vérité : la doc officielle

Tout ce qui est écrit doit correspondre à https://grafana.com/docs/k6/latest/ (k6 v2.x). Les références de cette skill résument cette doc. Si quelque chose n’est pas couvert, ou si vous avez le moindre doute sur une API, une option ou une métrique, consultez la page officielle (plan dans references/official-docs.md) plutôt que de vous fier à votre mémoire. De nombreux exemples sur Internet utilisent des API obsolètes (k6/experimental/browser, browser synchrone, browser_web_vital_fid) qui ne fonctionnent plus en v2.

Fichiers de référence (lisez uniquement ce dont vous avez besoin)

Fichier	Quand le lire
references/test-types.md	Toujours : choisir le type de test, le profil de stages et l’executor
references/thresholds-checks.md	Toujours : thresholds standards et comment écrire les checks
references/http-patterns.md	Tests d’API : cycle de vie, auth, secrets, corrélation, données
references/browser-patterns.md	Tests avec k6 browser ou hybrides
references/doc-template.md	Lors de la rédaction du .md explicatif
references/official-docs.md	Pour chercher la page officielle d’un sujet
assets/lib/config.js	Copier tel quel dans k6/lib/config.js
assets/templates/*	Base pour flows, tests, README, .secrets.example

Structure standard du projet

k6/
├── tests/
│   ├── api/        <type>-<flux>.js            ex. load-checkout.js, stress-search-products.js
│   └── browser/    <type>-<flux>-browser.js    ex. load-login-browser.js
├── lib/
│   ├── config.js   (copié depuis assets/lib/config.js)
│   ├── flows/      <flux>.js — les étapes utilisateur, réutilisées par tous les types
│   └── pages/      <page>-page.js — page objects (uniquement browser, si le flux comporte plusieurs pages)
├── data/           données de test JSON/CSV (jamais de credentials)
├── docs/           <même-nom-que-le-script>.md
├── .secrets.example
└── README.md       (depuis assets/templates/k6-README.md, avec l’index des scripts)

Noms : kebab-case, préfixe de type (smoke-, load-, stress-, spike-, soak-, breakpoint-) + flux métier descriptif (checkout, search-products, pas test1 ni api). Les scripts browser portent le suffixe -browser. Le .md porte exactement le même nom que le script.

Langue : commentaires et docs en français ; identifiants de code en anglais.

Si le projet possède déjà un dossier k6/, réutilisez config.js, les flows et les page objects existants au lieu de les dupliquer, et respectez ce qui est déjà en place.

Flux de travail

1. Comprendre la demande

Extrayez de ce que l’utilisateur a dit :

• Type de test : load, stress ou autre. S’il dit « voir jusqu’où ça tient » ou « pousser à la limite », c’est stress (ou breakpoint s’il veut le point de rupture exact). S’il dit « charge normale » ou « une journée typique », c’est load.
• API, browser ou hybride.
• Endpoints ou écrans et ordre du flux, comment il s’authentifie et ce que chaque étape valide.
• Charge (utilisateurs concurrents ou req/s), durée et SLA (ex. p95 < 500 ms).
• Environnement cible.

Ne demandez que ce qui bloque et ne peut pas raisonnablement être supposé : l’URL ou les endpoints s’ils ne sont pas donnés, et toujours si l’objectif est la production quand ce n’est pas clair. Le reste est supposé avec les valeurs par défaut des références (SLA 500 ms, think time 1-3 s, stress = 2× la charge load) et chaque hypothèse est écrite dans la section « Hypothèses » du .md. Si l’utilisateur ne connaît pas ses nombres de charge, dites-le-lui : sans eux, le test répond à une question différente de celle qui l’intéresse.

2. Préparer la structure

Créez ce qui manque dans k6/ : lib/config.js (copie exacte de assets/lib/config.js), .secrets.example avec les clés utilisées par le script, README.md à partir du template, et ajoutez au .gitignore du projet :

k6/.secrets
k6/screenshots/

3. Écrire le flux et les tests

• Flux dans k6/lib/flows/<flux>.js (base : assets/templates/flow-api.js). Il contient les requêtes, checks, groupes numérotés, tags name et think time. Si le flux nécessite une connexion, exportez une fonction login() appelée depuis setup().
• Test dans k6/tests/api/<type>-<flux>.js (base : assets/templates/test-api.js). Il définit uniquement options (scenario + thresholds), setup() et default(), qui appelle le flux. Les stages et thresholds sont explicites dans le fichier, avec un commentaire par ligne.
• Browser dans k6/tests/browser/<type>-<flux>-browser.js (base : assets/templates/test-browser.js). Par défaut, hybride : charge HTTP plus quelques VUs de browser. Lisez references/browser-patterns.md.
• Générez toujours aussi smoke-<flux>.js s’il n’existe pas. C’est peu coûteux (réutilise le flux) et c’est la première étape obligatoire avant un load ou un stress.
• Si on demande un stress et que le load du même flux n’existe pas, générez les deux : la doc officielle dit que le stress se lance après le load et réutilise son script.

Règles non négociables, car elles protègent l’équipe et les systèmes :

• Credentials, tokens et clés API uniquement via k6/secrets (await secrets.get('NOM')) avec --secret-source=file=k6/.secrets. Jamais dans le code, dans data/, dans les valeurs par défaut de __ENV ni dans un console.log.
• L’URL et l’environnement, via -e BASE_URL / -e TARGET_ENV lus depuis lib/config.js. Jamais en dur.
• Ne retirez ni n’affaiblissez la protection de production de config.js.
• Imports jslib avec version exacte (voir official-docs.md).
• Browser : k6/browser, fonctions async, options.browser.type: 'chromium' dans le scenario, page.close() dans finally, check de k6-utils pour les checks async, page.waitForTimeout() au lieu de sleep().
• Chaque requête avec un tag name stable ('GET /items/:id'), pour que les URL avec IDs n’explosent pas le nombre de métriques.

4. Écrire le .md explicatif

Un par script dans k6/docs/<nom>.md, en suivant toutes les sections de references/doc-template.md. Celui qui le lit n’est pas expert : expliquez chaque terme la première fois (VU, itération, p95, threshold), expliquez le pourquoi de chaque nombre et utilisez les valeurs réelles du script. Incluez le diagramme ASCII du profil de charge, le tableau des checks et thresholds « en mots », les commandes exactes pour l’exécuter (smoke d’abord) et les erreurs courantes. Ensuite, ajoutez le script à l’index de k6/README.md.

5. Valider

• Lancez k6 inspect -e BASE_URL=https://example.test -e TARGET_ENV=staging <script> sur chaque nouveau script. Cela détecte les erreurs de syntaxe, les imports cassés et les options invalides sans générer de charge. Si k6 n’est pas installé, dites-le et laissez la commande pour qu’ils l’exécutent.
• Une exécution réelle uniquement avec autorisation explicite de l’utilisateur et en smoke (peu de VUs et quelques secondes) contre un environnement qui n’est pas la production. Ne lancez jamais de load, stress, spike, soak ou breakpoint par vos propres moyens : ils génèrent une charge réelle sur des systèmes partagés.

6. Répondre

Réponse courte :

• Liste des fichiers créés ou modifiés.
• La commande pour exécuter le smoke puis le test demandé.
• Hypothèses principales (les mêmes que dans le .md).
• Ce que vous avez validé et ce que vous n’avez pas validé (par exemple, « passe k6 inspect ; n’a pas été exécuté contre l’API »).

Réviser ou corriger un script existant

Quand la demande est de comprendre, corriger ou améliorer un script :

1. Lisez-le en entier et confrontez-le au standard et à la doc officielle (API obsolètes, browser sans await, absence de page.close, credentials dans le code, pas de thresholds, pas de tags name, pas de think time, profils en « montagnes russes »).
2. Expliquez les problèmes en langage simple, classés par gravité, et proposez le changement.
3. En le corrigeant, mettez à jour (ou créez) son .md pour que la documentation reste en phase avec le code.
4. Si le nom ne suit pas le standard, suggérez le renommage, mais ne le faites pas sans confirmation, car cela pourrait casser les pipelines qui l’appellent.