IDE Testing Workflow

Use your IDE assistant to connect the code you write to the acceptance criteria your team reviews in Tanda. The assistant and the web app use the same SOW, test definitions, bindings, and code run records.

Connect your assistant using MCP Client Setup. To run repository tests, an administrator must also enable a runner connection for the project or SOW. The automated acceptance testing guide explains the web workflow and setup requirements.

1. Read the requirements and existing tests

"Open the checkout SOW with its task items, criteria, and tests. Show me which criteria have no tests."

The assistant uses get_sow with items, criteria, and tests included, and list_tests to read the test procedures. analyze_coverage and analyze_coverage_gaps help find missing definitions and propose improvements.

Coverage analysis tells you where tests are defined. It does not prove that the application passed those tests. Use get_code_test_runs to inspect actual code execution results.

2. Define a test for the criterion

"For 'My Tasks loads without an API error,' propose a procedure that checks the tasks request and the visible task list. Save the agreed test under that criterion."

The assistant can use create_test with a procedure containing preconditions, numbered steps, and the expected result. Those procedures appear in Tanda for your team to review. Edit an existing procedure in the web app; the current MCP tools do not expose a procedure update operation.

Defining a procedure does not create executable test code. A developer or IDE assistant still needs to write or identify a repository test that performs the check.

3. Link the code that verifies it

"Inspect this repository for an existing test of that behavior. Show me its assertions, file, framework, and test name. Link it to the Tanda acceptance test once we have confirmed that it covers the criterion."

Your IDE assistant needs access to the repository to inspect source files. Tanda's MCP connection provides the requirements and test records; it does not automatically scan the repository.

After reviewing the code, the assistant can:

1. Use get_execution_settings with action: "read" to inspect the approved connection, and get_code_test_runs with action: "settings" to read the existing bindings.
2. Use save_execution_settings when a project default or SOW override needs changing.
3. Use manage_code_test_run with action: "configure" to save the explicit test bindings, preserving existing bindings and supplying the current revision.
4. Commit the matching .tanda/tests.json with the tests in the repository.

Each binding identifies a Tanda acceptance test, stable key, framework, working directory, file, and optional test name or tags. A source-code reference attached to a record helps navigation; it becomes executable only when explicitly configured as a binding.

4. Start a run and inspect its report

"Run the linked checkout checks at this commit against staging through the approved GitHub connection. Show me the run ID and results when they arrive."

The assistant uses manage_code_test_run with action: "start", the SOW ID, full commit SHA, enabled environment, selected binding keys, execution mode, and a fresh idempotency key. Retrying an identical request uses the same key to avoid creating duplicate runs.

For GitHub execution, Tanda dispatches the configured workflow. For local or existing CI execution, it creates a run record and the operator executes or imports the tests using the runner. In either case, the runner submits the results. An assistant's opinion that code looks correct is not an executed test result.

The assistant reads progress and reports with get_code_test_runs. Your teammates can open Acceptance Test Procedure → Run code tests → Recent runs to see those same results. Start a new run after a fix to preserve both attempts and their original definitions, commits, environments, and evidence.

5. Review the evidence with your team

Share the SOW and identify the run being reviewed. Reviewers should check which criteria were covered, the commit and environment used, and any failed, skipped, or blocked checks. Artifact links may require access to your CI provider and can expire under its retention policy.

The SOW PDF contains the acceptance test procedures for document review and sign-off. Inspect automated execution reports and linked evidence in the code runs panel; a signed procedure is not proof that its code tests passed.

Tool reference

Changes require MCP write access and the appropriate Tanda editor permission. Runner credentials are managed by the administrator; they do not belong in prompts or test definitions.