IDE Testing Workflow

Not every team runs acceptance test packs or test automation — and they shouldn't have to. Tanda's MCP tools let the AI assistant in your IDE work with requirements and tests directly, while the rest of the organization works with a distributable PDF they can review, sign off on, and track changes to.

The loop looks like this:

1. Ask what the requirements are — your assistant pulls the full checklist from Tanda
2. Define the tests — the assistant helps write test procedures and saves them back
3. Check for gaps while coding — "do we meet all the tests?" gets a concrete answer
4. Record a verification pass — results are persisted for the audit trail and reports
5. Distribute and sign off — the SOW PDF carries the acceptance test procedure and signature pages

1. Ask What the Requirements Are

"What are the requirements for the checkout SOW?"

The assistant calls get_requirements_checklist, which returns everything in one shot: the SOW scope, user stories, every task item with its acceptance criteria, every test with its full step-by-step procedure, the latest run status per test, and gap counts.

A requirement like "the page needs to be blue" comes back as an acceptance criterion, with its tests attached — or flagged with ⚠️ if no test exists yet.

2. Define the Tests and Test Procedures

"The 'page is blue' criterion has no test. Define one: load the page and validate the background color is blue."

The assistant calls create_test with the full procedure inline (or set_test_procedure for an existing test). Procedures support two formats:

Procedural — numbered steps with expected results:

{
  "step": 1,
  "action": "Navigate to /dashboard",
  "expected": "Page loads with background color #1e40af (blue)"
}

BDD — given/when/then:

{ "type": "given", "text": "The user is signed in" }
{ "type": "when", "text": "They open the dashboard" }
{ "type": "then", "text": "The page background is blue" }

Procedures written from the IDE appear immediately in the Tanda web app and in the exported SOW PDF — this works both ways: the AI can author procedures, and it can read procedures your team wrote in the web app.

3. Check for Gaps While Writing Code

"Do we meet all of the tests?"

The assistant re-fetches the checklist, reads each test's steps, and checks them against the code it can see. Because the checklist includes coverage counts (items without criteria, criteria without tests) and per-test last-run status, it can answer precisely:

• which requirements have no tests at all,
• which tests exist but have never been run,
• which tests failed in the last run.

This is read-only — nothing is written to Tanda, so quick glances stay cheap.

4. Record a Formal Verification Pass

When you want the check to count — for the audit trail, the report, or client sign-off — the assistant runs it as a test run:

Runs are attributed to the user (or API token) that executed them and are visible to the whole team. Use list_test_runs and get_test_run to review history.

5. Distribute the Document and Get Sign-Off

The SOW PDF export includes the Acceptance Test Procedure — every test with its sections, prerequisites, and steps — plus approver signature pages and a version change log. That's the artifact you distribute inside the organization:

• Reviewers receive it via email distribution with public signing links
• Signatures are captured digitally (name, timestamp, hash) — see versioning for how changes between versions are tracked
• No Tanda account is required for external signers

So the developer experience stays in the IDE, and the organizational experience stays a signed, versioned document.

Tool Reference