product: maestro audience: test-developer authority: normative

Checklist: New Package

Recommended development sequence

 1.  Scaffold via TAT UI
 2.  Open in VS Code; verify package.json
 3.  Write .NET test code
 4.  Publish runner project → `dotnet publish <YourProject>.csproj -c Release -o assemblies/ --no-self-contained`
 5.  Write YAML test definition(s)  ← VS Code gives live schema feedback here
 6.  Validate: py validate.py       ← level 1 immediately; level 2 when stack is up
 7.  Run test (mock or real hardware)
 8.  Verify results in Test Results page
 9.  Handle Python dependencies (if applicable)
10.  Bump version in package.json
11.  Write README.md
12.  Git commit and push

Checklist

• Choose a package name — <ProductId>_<TestName>_v<NN>: ESH10000121_FunctionalTest_v00
• Scaffold via TAT UI — /packages → New Package
• Open in VS Code — File → Open Folder; install redhat.vscode-yaml extension
• Verify package.json — name, version, author, description; set requirements.minDotNetVersion for .NET packages

.NET test code (if applicable)

• Write test methods — one method per logical operation (see sdk/design-principle.md)
• Add [assembly: DoNotParallelize] in MSTestSettings.cs (see sdk/mstest-debugging.md)
• Run dotnet publish <YourProject>.csproj -c Release -o assemblies/ --no-self-contained — verify assemblies/<YourProject>.dll exists and commit the assemblies/ folder

Accordion instrument (if applicable)

• Add AccordionQ2.WebApiClient NuGet reference to runner .csproj (not MSTest project)
• Implement Connect / Disconnect and wire as YAML setup / teardown steps
• Store agent host address in Station Config (AGENT_HOST); reference via {{cfg.AGENT_HOST}}
• See getting-started/accordion-q2-client.md and ../Accordion/05-api-dotnet/

YAML test definitions

• test.name and test.version set
• All variables declared in variables: block
• Every measurement has a name and unit
• Limits are in correct order (low_limit < high_limit)
• Critical setup steps have post_execution_action: terminate-on-fail
• Cleanup steps have run_on_abort: true
• repeat: blocks have max_iterations set
• All hardware runner steps have timeout_ms set
• Steps that use a shared instrument declare requires: (e.g. [dmm, mux]) — safe to add even on single-execution stations
• The Connect setup step has retry: configured

Validation and testing

• Run py validate.py — all files must pass
• Run the test with mock steps or real hardware
• Verify results appear correctly in Test Results page

Python dependencies (if applicable)

• requirements.pipPackages declared in package.json
• Wheels vendored in wheels/ for production (see sdk/python-dependencies.md)
• Tested in runner container with python -c "import mypackage"

Final steps

• Bump version in package.json before every commit that will be deployed
• Write README.md
• Git commit and push