Skip to main content
Glama

gentest

Generate comprehensive test cases for code using Jest, Vitest, or Mocha frameworks to ensure code reliability and quality.

Instructions

【生成测试】为代码生成完整的测试用例(支持 Jest/Vitest/Mocha)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNo需要测试的代码
frameworkNo测试框架:jest, vitest, mocha(默认 jest)

Implementation Reference

  • The gentest tool handler function. It takes args with code and optional framework, constructs a detailed prompt for generating comprehensive test cases (unit, integration, edge, error cases) following AAA pattern, with mocks, data factories, etc., and returns it as MCP content.
    export async function gentest(args: any) {
      try {
        const code = args?.code || "";
        const framework = args?.framework || "jest"; // jest, vitest, mocha
    
        const message = `请为以下代码生成完整的测试用例:
    
    📝 **代码内容**:
    ${code || "请提供需要测试的代码"}
    
    🧪 **测试框架**:${framework}
    
    ---
    
    ## 测试用例生成指南
    
    ### 1️⃣ 测试策略
    
    **测试类型**:
    - **单元测试**:测试单个函数/方法
    - **集成测试**:测试模块间交互
    - **边界测试**:测试极端情况
    - **异常测试**:测试错误处理
    
    **覆盖维度**:
    - ✅ 正常情况(Happy Path)
    - ✅ 边界条件(Boundary Conditions)
    - ✅ 异常情况(Error Cases)
    - ✅ 空值/特殊值(Null/Special Values)
    
    ### 2️⃣ 测试用例模板
    
    **测试结构(AAA 模式)**:
    \`\`\`typescript
    describe('函数/模块名称', () => {
      // Arrange - 准备测试数据
      // Act - 执行被测试的代码
      // Assert - 验证结果
      
      test('描述测试场景', () => {
        // Arrange
        const input = ...;
        const expected = ...;
        
        // Act
        const result = functionUnderTest(input);
        
        // Assert
        expect(result).toBe(expected);
      });
    });
    \`\`\`
    
    ### 3️⃣ 测试用例清单
    
    **正常情况测试**:
    - [ ] 基本功能正常工作
    - [ ] 返回值类型正确
    - [ ] 副作用符合预期
    
    **边界条件测试**:
    - [ ] 空输入(null, undefined, "", [], {})
    - [ ] 最小值/最大值
    - [ ] 边界临界值
    
    **异常情况测试**:
    - [ ] 无效输入
    - [ ] 类型错误
    - [ ] 超出范围
    - [ ] 异常抛出正确
    
    **性能测试(可选)**:
    - [ ] 大数据量处理
    - [ ] 时间复杂度验证
    
    ### 4️⃣ Mock 和 Stub
    
    **需要 Mock 的场景**:
    - API 调用
    - 数据库操作
    - 文件系统操作
    - 时间相关函数
    - 随机数生成
    - 外部依赖
    
    **Mock 示例**:
    \`\`\`typescript
    // Mock 函数
    const mockFetch = jest.fn();
    
    // Mock 模块
    jest.mock('./api', () => ({
      fetchUser: jest.fn().mockResolvedValue({ id: 1, name: 'Test' })
    }));
    
    // Mock 时间
    jest.useFakeTimers();
    \`\`\`
    
    ### 5️⃣ 测试数据
    
    **测试数据原则**:
    - 使用有意义的测试数据
    - 避免硬编码,使用工厂函数
    - 覆盖各种数据类型
    - 准备充分的边界数据
    
    **数据工厂示例**:
    \`\`\`typescript
    const createUser = (overrides = {}) => ({
      id: 1,
      name: 'Test User',
      email: 'test@example.com',
      ...overrides
    });
    \`\`\`
    
    ---
    
    ## 测试文件命名规范
    
    - **单元测试**:\`functionName.test.ts\` 或 \`functionName.spec.ts\`
    - **集成测试**:\`moduleName.integration.test.ts\`
    - **E2E 测试**:\`feature.e2e.test.ts\`
    
    ---
    
    现在请生成完整的测试代码,包括:
    1. describe 块组织
    2. 所有必要的测试用例
    3. Mock/Stub 设置
    4. 测试数据准备
    5. 清晰的注释说明`;
    
        return {
          content: [
            {
              type: "text",
              text: message,
            },
          ],
        };
      } catch (error) {
        const errorMessage =
          error instanceof Error ? error.message : String(error);
        return {
          content: [
            {
              type: "text",
              text: `❌ 生成测试用例失败: ${errorMessage}`,
            },
          ],
          isError: true,
        };
      }
    }
  • Schema definition for the gentest tool in the ListTools response, specifying input parameters: code (string) and framework (string, default jest).
    {
      name: "gentest",
      description: "【生成测试】为代码生成完整的测试用例(支持 Jest/Vitest/Mocha)",
      inputSchema: {
        type: "object",
        properties: {
          code: {
            type: "string",
            description: "需要测试的代码",
          },
          framework: {
            type: "string",
            description: "测试框架:jest, vitest, mocha(默认 jest)",
          },
        },
        required: [],
      },
    },
  • src/index.ts:480-481 (registration)
    Registration in the CallToolRequestHandler switch statement: dispatches to the gentest function when tool name is 'gentest'.
    case "gentest":
      return await gentest(args);
  • src/tools/index.ts:8-8 (registration)
    Export of the gentest handler from src/tools/index.ts, allowing import in src/index.ts.
    export { gentest } from "./gentest.js";
  • src/index.ts:12-15 (registration)
    Import of gentest function from tools/index.js into the main index.ts for use in tool handlers.
      detectShell, initSetting, initProject, gencommit, debug, genapi,
      codeReview, gentest, genpr, checkDeps, gendoc, genchangelog, refactor, perf,
      fix, gensql, resolveConflict, genui, explain, convert, genreadme, split, analyzeProject
    } from "./tools/index.js";
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It states the tool generates test cases but doesn't disclose behavioral traits such as whether it modifies existing files, requires specific permissions, handles errors, or produces output format. For a code generation tool with zero annotation coverage, this is inadequate, though it's not misleading.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded in a single sentence, efficiently stating the core functionality and framework support. There's no wasted text, but it could be slightly more structured (e.g., separating purpose from details) to enhance clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (code generation with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the generated test cases look like, how they're returned, or any limitations. For a tool that likely produces structured output, this leaves significant gaps for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with clear parameter descriptions in Chinese. The description adds minimal value beyond the schema by mentioning framework support, but doesn't provide additional semantics like examples or constraints. With high schema coverage, the baseline is 3, and the description meets this without compensating further.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: '为代码生成完整的测试用例' (generate complete test cases for code). It specifies the verb (generate) and resource (test cases) with the target (code). However, it doesn't explicitly differentiate from sibling tools like 'analyze_project' or 'debug' that might also involve testing-related functionality, so it doesn't reach the highest score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides minimal guidance: it mentions support for Jest/Vitest/Mocha frameworks, but doesn't specify when to use this tool versus alternatives like 'analyze_project' for project-level analysis or 'debug' for troubleshooting. There's no explicit when/when-not usage or prerequisite information, leaving gaps for the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mybolide/mcp-probe-kit'

If you have feedback or need assistance with the MCP directory API, please join our Discord server