An n8n agent writes test cases using a use case from Pachca and requirements from Yandex Wiki

Dropping a use case into a chatbot will not get you decent test cases: bugs hide in the details, and the model does not have those details. It needs context: requirements, tickets, and conversations. Providing that context takes integrations. The author of a Habr walkthrough demonstrates a minimal version of this pipeline in n8n, from a message in a work chat to a finished test case.

What we are building and what it runs on

n8n is an agent builder that connects models to code, issue trackers, CI, and other infrastructure. Each action is a separate node, and nodes fit together into a workflow like Lego bricks. Workflows can be exported as JSON. The source code is publicly available: in n8n's cloud, you pay for hosting and each execution; on your own infrastructure, it is free. With more than 2600 integrations, you can build an agent for most stacks. For example, it could generate test cases from Jira tickets and GitHub documentation, with search handled through Pinecone.

The article uses a simpler scenario. The requirement lives in Yandex Wiki, and the use case is in a Pachca chat. The logic has four steps:

• the agent waits for a user to post a use case in the chat;
• it replies to the message with a request to submit the requirement page's URL through a form;
• it sends the use case and requirement to the model;
• it returns the response to the use case's thread.

How to connect Pachca and Wiki

On the Pachca side, you need to create a bot and enable its outgoing webhook. The author highlights three options: ignore its own messages so the bot does not trigger itself, listen to all messages, and respond to button clicks. The system displays the token only once, so save it immediately. The required permissions are messages:read, messages:create, threads:read, threads:create, and views:write. The last one lets the user submit the requirement URL through a form. Enter the webhook URL and signing key in the n8n trigger.

There is a catch. The Execute button listens on a test URL rather than your URL, so you cannot test the trigger that way. That leaves two options: create a separate test bot or publish the workflow. In a published workflow, triggers pick up events automatically, and results appear in the Executions tab.

Yandex Wiki is more involved: there is no ready-made node, but an MCP server works. You need an OAuth application with wiki:read permission, a token obtained through an authorization link containing your ClientID, and an organization identifier. For Yandex 360 for Business, this is X-Org-ID; for Yandex Cloud Organization, it is X-Cloud-Org-ID. In n8n's Credentials, create a Multiple Headers Auth entry with two headers: Authorization and the organization header.

There are then two options. The square MCP Client node calls a tool directly. The round MCP Client Tool node connects to the model node, leaving the model to decide what to request. The author chose a direct call: HTTP Streamable, endpoint mcp.wiki.yandex.net, tool GetPageById. The snag is the page ID: you can obtain it only through the Wiki API by querying its slug, for example with curl using the token and organization header.

Results and limitations

Data moves between nodes as JSON, and you access the previous node's output through $json.variable_name. The easiest way to find variable names is to check the Executions tab after any run, even a failed one. The result: the bot receives a use case, asks for a link to the requirement, and returns a test case in the thread. The author published the finished workflow on GitHub as JSON.

For now, this demonstrates capabilities rather than assessing quality. There are no metrics: the article does not say how closely the generated test cases match manually written ones or how many bugs they miss. The author also warns about pitfalls: the tool cannot retrieve requirements that exist only in the customer's head, and it will not eliminate hallucinations or manual checks. Those issues will be covered in the next article.

What to do in practice. If your team already uses Pachca and Wiki, you can recreate the workflow in an evening. A direct MCP call is enough for the first run: it is more predictable than letting the model choose the tool. That is our assessment; the article does not make this comparison. Keep authentication details in Credentials rather than in the nodes themselves. Check the results on 5–10 real use cases and compare them with what a tester would write. Only then should you decide whether an agent like this belongs in your process.