get_rules_for_writing_tests
Retrieve language-specific testing guidelines including naming conventions, structure, assertions, mocking approaches, and coverage requirements before writing or modifying test code.
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:64-92 (registration)Registers the MCP tool 'get_rules_for_writing_tests' with its description, input schema (language enum), and handler function that uses getInstructions to return combined testing rules.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, providing the core logic executed by the tool handler.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/mcp-server.ts:13-17 (helper)Defines the supported programming languages used for the tool's input schema and instructions selection.export type supportedLanguage = "typescript" | "python"; export const supportedLanguages: [supportedLanguage, ...supportedLanguage[]] = [ "typescript", "python" ];
- src/generated/instructions.ts:3-9 (helper)Defines the type and static data for testing instructions (general, TypeScript, Python) consumed by the getInstructions helper.export type TestingInstructions = { general: string; typescript: string; python: string; }; 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"};
- src/mcp-server.ts:74-77 (schema)Zod schema for the tool's input parameter 'language', validating against supported languages.language: z .enum(supportedLanguages) .describe("The programming language the test is written in.") },