Initialisation de framework de test

VérifiéPrudence

Initialiser une architecture de framework de test prête pour la production avec Playwright ou Cypress, incluant fixtures, helpers et configuration.

Spar Skills Guide Bot
TestingIntermédiaire
0030/08/2026
Claude Code
#test-framework#playwright#cypress#test-automation#configuration

Recommandé pour

Notre avis

Initialise un framework de test prêt pour la production (Playwright ou Cypress) avec fixtures, helpers et configuration, en suivant un flux de travail personnalisable.

Points forts

  • Prend en charge à la fois Playwright et Cypress
  • Inclut configuration et fixtures pour une mise en place professionnelle
  • Personnalisable via un système de configuration en couches (base/équipe/utilisateur)
  • Flux de travail clair avec modes création, validation et édition

Limites

  • Dépend fortement d'une structure de projet spécifique (scripts et configs `_bmad`)
  • Peut être excessif pour des configurations de test simples
  • Nécessite Python pour résoudre la personnalisation
Quand l'utiliser

Lorsque vous devez rapidement mettre en place un framework de test automatisé robuste avec Playwright ou Cypress dans un projet utilisant le système de personnalisation bmad.

Quand l'éviter

Pour un test ponctuel simple ou lorsque le projet ne dispose pas de l'infrastructure `_bmad` requise.

Analyse de sécurité

Prudence
Score qualité78/100

The skill orchestrates a workflow by executing a local Python script and running arbitrary activation steps defined in configuration files. While the visible content does not contain destructive or exfiltrating commands, it delegates execution control to customizable files that could be modified to perform unintended actions, making it a caution-level risk.

Points d'attention
  • Runs a Python script from the project's `_bmad/scripts` directory, which could be malicious if the project is compromised.
  • Executes all entries in `activation_steps_prepend` and `activation_steps_append` from customizable TOML files, allowing arbitrary commands to be executed as part of the workflow.
  • Loads files matched by `persistent_facts` globs, which may cause reading of sensitive project files if configured to do so.

Exemples

Setup Playwright
Let's set up a Playwright test framework for our project.
Initialize Cypress
I want to initialize a Cypress testing framework.
Test framework setup
Please set up an end-to-end test framework with fixtures and helpers.

name: bmad-testarch-framework description: 'Initialize test framework with Playwright or Cypress. Use when the user says "lets setup test framework" or "I want to initialize testing framework"'

Test Framework Setup

Goal: Initialize a production-ready test framework architecture (Playwright or Cypress) with fixtures, helpers, and configuration.

Role: You are the Master Test Architect.

You will continue to operate with your given name, identity, and communication_style, merged with the details of this role description.

Conventions

  • Bare paths (e.g. instructions.md) resolve from the skill root.
  • {skill-root} resolves to this skill's installed directory (where customize.toml lives).
  • {project-root}-prefixed paths resolve from the project working directory.
  • {skill-name} resolves to the skill directory's basename.
  • Resolve sibling workflow files such as instructions.md, checklist.md, steps-c/..., steps-e/..., steps-v/..., and templates from {skill-root}.

On Activation

Step 1: Resolve the Workflow Block

Run: python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow

If the script fails, resolve the workflow block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:

  1. {skill-root}/customize.toml — defaults
  2. {project-root}/_bmad/custom/{skill-name}.toml — team overrides
  3. {project-root}/_bmad/custom/{skill-name}.user.toml — personal overrides

Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by code or id replace matching entries and append new entries, and all other arrays append.

Step 2: Execute Prepend Steps

Execute each entry in {workflow.activation_steps_prepend} in order before proceeding.

Step 3: Load Persistent Facts

Treat every entry in {workflow.persistent_facts} as foundational context you carry for the rest of the workflow run. Entries prefixed file: are paths or globs resolved from {project-root} — expand them and load every matching file in lexical path order as facts. All other entries are facts verbatim.

Step 4: Load Config

Load config from {project-root}/_bmad/tea/config.yaml and resolve:

  • user_name
  • communication_language

Step 5: Greet the User

Greet {user_name}, speaking in {communication_language}.

Step 6: Execute Append Steps

Execute each entry in {workflow.activation_steps_append} in order.

Activation is complete. Begin the workflow below.

Workflow Architecture

This workflow uses tri-modal step-file architecture:

  • Create mode (steps-c/): primary execution flow for new runs and resume continuation
  • Validate mode (steps-v/): validation against checklist
  • Edit mode (steps-e/): revise existing outputs

Initialization Sequence

1. Mode Determination

"Welcome to the workflow. What would you like to do?"

  • [C] Create — Run the workflow from the beginning
  • [R] Resume — Resume an interrupted Create workflow
  • [V] Validate — Validate existing outputs
  • [E] Edit — Edit existing outputs

2. Route to First Step

  • If C: Load {skill-root}/steps-c/step-01-preflight.md
  • If R: Load {skill-root}/steps-c/step-01b-resume.md (Create-mode continuation)
  • If V: Load {skill-root}/steps-v/step-01-validate.md
  • If E: Load {skill-root}/steps-e/step-01-assess.md
Skills similaires