How to use the E2E Testing skill for Qwen Code agents

What the skill makes the agent do

Without the skill, an agent has to work out the steps for end-to-end testing on its own. With it, the agent follows a documented process: choose the right binary, run the CLI in headless JSON mode or in an interactive tmux session, and capture the raw requests sent to the model.

The skill also points to helper files: a zero-dependency MCP test server template, a mock OpenAI-style model server for scripted scenarios, and a token usage summary script for logged requests.

• Reproduce user-reported bugs using the globally installed qwen command
• Verify fixes by building and running node dist/cli.js
• Test MCP tool integrations with a custom test server
• Inspect raw API request and response payloads
• Summarise token usage from logged API calls

How do you install the e2e-testing skill?

Download the skill ZIP from this page and unzip it into one of two locations. For a personal setup, unzip it into ~/.claude/skills/. For a single project, unzip it into that project's .claude/skills/ folder.

In the Claude apps you can instead upload the ZIP under Settings → Capabilities → Skills.

• Personal: ~/.claude/skills/
• Project: .claude/skills/ inside your project
• Claude apps: Settings → Capabilities → Skills

What do you need before running the tests?

The skill assumes the Qwen Code repository and its setup. Plan for the following before asking the agent to run anything.

• Node.js and npm, to build and run the CLI
• Python 3, for scripts/token-stats.py
• tmux, for interactive terminal testing
• The Qwen Code CLI installed globally or built from the repository
• Model provider credentials stored in ~/.qwen (for example an OpenAI-compatible or Anthropic key), needed for real model calls
• Network access, since the tests call a live model

How do you trigger the skill with natural requests?

The skill's description lists the phrases that should activate it. You do not need to name the skill. Ask for what you want verified, using words such as E2E testing, headless testing, MCP tool testing, or reproducing an issue.

Describe the bug or behaviour in the request and say whether you want a real model call. The agent will then choose headless or interactive mode based on what you need to see.

• Run an E2E test of this bug report against a real model in headless mode
• Verify my fix works in the built bundle with real model calls
• Test how the CLI handles my custom MCP tool server
• Capture the raw API requests for this prompt and show the tool arguments
• Reproduce this issue end to end and report the token usage

How do headless and interactive modes work?

Headless mode runs the CLI non-interactively and prints one JSON array of messages at the end of the turn. Interactive mode runs the CLI inside a tmux session, which is useful for checking what the user sees, permission prompts, slash commands and keyboard input.

To force a known provider, the skill passes --auth-type together with --model. --model alone does not switch providers.

• Headless: use --output-format json and filter with jq, starting with .[]
• Interactive: launch in tmux, send prompts, poll for the esc to cancel status line, then capture the pane
• Use QWEN_RUNTIME_DIR to keep test runs out of your real chat history

How do you test MCP servers and inspect API traffic?

For MCP testing, the skill says MCP servers must be configured in .qwen/settings.json under mcpServers. Other locations such as .mcp.json or a --mcp-config flag do not work for Qwen Code. The CLI also needs a git repository to load project settings.

To inspect raw traffic, add the logging flags. Each API call is written as a JSON file in the directory you specify. The file's request.messages holds the conversation history, and response.choices holds the model's reply.

• MCP config: .qwen/settings.json under mcpServers
• Use references/mcp-testing.md and scripts/mcp-test-server.js as the starting point
• Use references/mock-openai-server.md when you need deterministic or unusual model responses
• Summarise token usage with python3 scripts/token-stats.py 20

What safety precautions apply?

The tests use real API keys from ~/.qwen. A real model call can cost money, and a run that is not isolated can write to your chat history or auto-memory. The skill includes scripts and makes network calls, so read them before running them on a machine you care about.

Use a throwaway directory and QWEN_RUNTIME_DIR for experiments. Avoid running the skill against real accounts on shared machines without care.

• Real keys in ~/.qwen can spend money on each model call
• Runs can write chat recordings, auto-memory and history unless QWEN_RUNTIME_DIR is set
• The skill runs scripts and uses the network, so review them first
• Unsupported key combinations in tmux may need manual testing

Tips for reliable E2E runs

Keep the runs small and specific. Use headless mode for structured output and interactive mode only when the bug involves the terminal interface. When polling a tmux session, wait for the esc to cancel status line to disappear rather than sleeping for a fixed time, because the footer placeholder is always visible.

• Split prompt text and Enter with a short delay in tmux, or the submit may be swallowed
• Use --auth-type with --model to pick a provider reliably
• Use tmux capture-pane -p -S -100 to read the last 100 lines of scrollback
• Kill the tmux session when you finish