get_rules_for_writing_tests
Retrieve user-specific guidelines for writing tests, including naming conventions, structure, assertions, mocking, and coverage. Use before writing or modifying test code to ensure adherence to defined patterns and preferences.
Instructions
Use when: writing any type of test, modifying existing tests, reviewing test structure, or making decisions about test implementation.
What it provides: User-specific rules, patterns, and preferences for test composition including naming conventions, structure, assertions, mocking approaches, and coverage requirements.
How to use: ALWAYS invoke this tool BEFORE writing or modifying any test code to retrieve the current testing guidelines, then apply these rules throughout your implementation.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| language | Yes | The programming language the test is written in. |
Implementation Reference
- src/mcp-server.ts:78-91 (handler)The async handler function that implements the tool logic by fetching and returning combined testing instructions for the specified language.async ({ language }): Promise<CallToolResult> => { const combinedInstructions = getInstructions("testing", language); return { content: [ { type: "text", text: combinedInstructions || `No instructions found for ${language} tests.` } ] }; }
- src/mcp-server.ts:73-77 (schema)Zod schema defining the input parameter 'language' which must be one of the supported languages.{ language: z .enum(supportedLanguages) .describe("The programming language the test is written in.") },
- src/mcp-server.ts:64-92 (registration)Registration of the 'get_rules_for_writing_tests' tool on the MCP server, including description, input schema, and inline handler.server.tool( "get_rules_for_writing_tests", ` Use when: writing any type of test, modifying existing tests, reviewing test structure, or making decisions about test implementation. What it provides: User-specific rules, patterns, and preferences for test composition including naming conventions, structure, assertions, mocking approaches, and coverage requirements. How to use: ALWAYS invoke this tool BEFORE writing or modifying any test code to retrieve the current testing guidelines, then apply these rules throughout your implementation. `, { language: z .enum(supportedLanguages) .describe("The programming language the test is written in.") }, async ({ language }): Promise<CallToolResult> => { const combinedInstructions = getInstructions("testing", language); return { content: [ { type: "text", text: combinedInstructions || `No instructions found for ${language} tests.` } ] }; } );
- src/mcp-server.ts:20-40 (helper)Helper function that combines general and language-specific testing instructions.export function getInstructions( action: string, language?: supportedLanguage ): string { const instructions: string[] = []; if (action === "testing") { // Always include testing general instructions instructions.push(TESTING_INSTRUCTIONS.general); // Include language-specific instructions if provided if (language) { const langInstructions = TESTING_INSTRUCTIONS[language]; if (langInstructions) { instructions.push(langInstructions); } } } return instructions.join("\n\n---\n\n"); }
- src/generated/instructions.ts:9-9 (helper)The data source containing general, TypeScript, and Python specific testing instructions used by the tool.export const TESTING_INSTRUCTIONS: TestingInstructions = {"general":"- The first line of every test file should be a comment containing an apple emoji: `# 🍎` \n- Code is transient. Tests are forever. Write tests for the LLM after you, the one that will be rewriting the application in 6 months and porting it to a new technology. \n- Before testing a protected method, ask \"Can this logic be adequately tested through the public interface?\". If yes, don't test the protected method directly. If no, continue testing the protected method.\n- Arrange, Act, Assert is a good pattern.\n- Vague test names using words like \"correct\", \"properly\", or \"should work\" make it difficult to understand what broke when tests fail and should therefore be avoided. \n- Do not test things like \"if I mock X to return Y, X should return Y\".","typescript":"# TypeScript Testing Instructions\n\n- Always use `data-testid` attributes over css selectors.","python":"# Python Testing Instructions\n\n- All tests should go into the top level tests directory\n- Each test name follows the pattern: test_when_[INPUT]_[ACTION]_[EXPECTED_OUTPUT]\n"};