Skip to main content
Glama

테스트 러너 MCP

여러 테스트 프레임워크의 테스트 결과를 실행하고 파싱하는 모델 컨텍스트 프로토콜(MCP) 서버입니다. 이 서버는 테스트를 실행하고 결과를 처리하는 통합 인터페이스를 제공하며, 다음을 지원합니다.

  • 배츠(Bash 자동 테스트 시스템)

  • Pytest(Python 테스트 프레임워크)

  • 플러터 테스트

  • Jest(JavaScript 테스트 프레임워크)

  • 고 테스트

  • 녹 테스트(화물 테스트)

  • 일반(임의의 명령 실행용)

설치

지엑스피1

Related MCP server: Tailscale MCP Server

필수 조건

각 테스트 유형에 대해 다음 테스트 프레임워크를 설치해야 합니다.

용법

구성

MCP 설정에 테스트 러너를 추가합니다(예: claude_desktop_config.json 또는 cline_mcp_settings.json ):

{
  "mcpServers": {
    "test-runner": {
      "command": "node",
      "args": ["/path/to/test-runner-mcp/build/index.js"],
      "env": {
        "NODE_PATH": "/path/to/test-runner-mcp/node_modules",
        // Flutter-specific environment (required for Flutter tests)
        "FLUTTER_ROOT": "/opt/homebrew/Caskroom/flutter/3.27.2/flutter",
        "PUB_CACHE": "/Users/username/.pub-cache",
        "PATH": "/opt/homebrew/Caskroom/flutter/3.27.2/flutter/bin:/usr/local/bin:/usr/bin:/bin"
      }
    }
  }
}

참고: Flutter 테스트의 경우 다음을 교체해야 합니다.

  • /opt/homebrew/Caskroom/flutter/3.27.2/flutter 실제 Flutter 설치 경로로 지정합니다.

  • /Users/username/.pub-cache 에 실제 pub 캐시 경로를 추가합니다.

  • 시스템의 실제 경로를 포함하도록 PATH를 업데이트하세요.

다음을 실행하여 이러한 값을 찾을 수 있습니다.

# Get Flutter root
flutter --version

# Get pub cache path
echo $PUB_CACHE   # or default to $HOME/.pub-cache

# Get Flutter binary path
which flutter

테스트 실행

다음 매개변수와 함께 run_tests 도구를 사용하세요.

{
  "command": "test command to execute",
  "workingDir": "working directory for test execution",
  "framework": "bats|pytest|flutter|jest|go|rust|generic",
  "outputDir": "directory for test results",
  "timeout": "test execution timeout in milliseconds (default: 300000)",
  "env": "optional environment variables",
  "securityOptions": "optional security options for command execution"
}

각 프레임워크의 예:

// Bats
{
  "command": "bats test/*.bats",
  "workingDir": "/path/to/project",
  "framework": "bats",
  "outputDir": "test_reports"
}

// Pytest
{
  "command": "pytest test_file.py -v",
  "workingDir": "/path/to/project",
  "framework": "pytest",
  "outputDir": "test_reports"
}

// Flutter
{
  "command": "flutter test test/widget_test.dart",
  "workingDir": "/path/to/project",
  "framework": "flutter",
  "outputDir": "test_reports",
  "FLUTTER_ROOT": "/opt/homebrew/Caskroom/flutter/3.27.2/flutter",
  "PUB_CACHE": "/Users/username/.pub-cache",
  "PATH": "/opt/homebrew/Caskroom/flutter/3.27.2/flutter/bin:/usr/local/bin:/usr/bin:/bin"
}

// Jest
{
  "command": "jest test/*.test.js",
  "workingDir": "/path/to/project",
  "framework": "jest",
  "outputDir": "test_reports"
}

// Go
{
  "command": "go test ./...",
  "workingDir": "/path/to/project",
  "framework": "go",
  "outputDir": "test_reports"
}

// Rust
{
  "command": "cargo test",
  "workingDir": "/path/to/project",
  "framework": "rust",
  "outputDir": "test_reports"
}

// Generic (for arbitrary commands, CI/CD tools, etc.)
{
  "command": "act -j build",
  "workingDir": "/path/to/project",
  "framework": "generic",
  "outputDir": "test_reports"
}

// Generic with security overrides
{
  "command": "sudo docker-compose -f docker-compose.test.yml up",
  "workingDir": "/path/to/project",
  "framework": "generic",
  "outputDir": "test_reports",
  "securityOptions": {
    "allowSudo": true
  }
}

보안 기능

테스트 러너에는 특히 generic 프레임워크에 대해 잠재적으로 유해한 명령의 실행을 방지하기 위한 내장 보안 기능이 포함되어 있습니다.

  1. 명령 검증

    • 기본적으로 sudo 및 su 차단합니다.

    • rm -rf / 와 같은 위험한 명령을 방지합니다.

    • 안전한 위치 외부에서 파일 시스템 쓰기 작업을 차단합니다.

  2. 환경 변수 정리

    • 잠재적으로 위험한 환경 변수를 필터링합니다.

    • 중요한 시스템 변수의 재정의를 방지합니다.

    • 안전한 경로 처리를 보장합니다

  3. 구성 가능한 보안

    • 필요한 경우 securityOptions 통해 보안 제한을 재정의합니다.

    • 보안 기능에 대한 세분화된 제어

    • 표준 테스트 사용을 위한 기본 안전 설정

구성할 수 있는 보안 옵션:

{
  "securityOptions": {
    "allowSudo": false,        // Allow sudo commands
    "allowSu": false,          // Allow su commands
    "allowShellExpansion": true, // Allow shell expansion like $() or backticks
    "allowPipeToFile": false   // Allow pipe to file operations (> or >>)
  }
}

플러터 테스트 지원

테스트 러너에는 Flutter 테스트에 대한 향상된 지원이 포함되어 있습니다.

  1. 환경 설정

    • 자동 Flutter 환경 구성

    • PATH 및 PUB_CACHE 설정

    • 플러터 설치 검증

  2. 오류 처리

    • 스택 추적 수집

    • 어설션 오류 처리

    • 예외 캡처

    • 테스트 실패 감지

  3. 출력 처리

    • 테스트 출력 캡처 완료

    • 스택 추적 보존

    • 자세한 오류 보고

    • 원시 출력 보존

녹 테스트 지원

테스트 러너는 Rust의 cargo test 에 대한 특정 지원을 제공합니다.

  1. 환경 설정

    • 더 나은 오류 메시지를 위해 RUST_BACKTRACE=1을 자동으로 설정합니다.

  2. 출력 구문 분석

    • 개별 테스트 결과를 구문 분석합니다.

    • 실패한 테스트에 대한 자세한 오류 메시지를 캡처합니다.

    • 무시된 테스트를 식별합니다.

    • 요약 정보를 추출합니다

일반 테스트 지원

CI/CD 파이프라인, act 통한 GitHub Actions 또는 기타 명령 실행의 경우 일반 프레임워크는 다음을 제공합니다.

  1. 자동 출력 분석

    • 출력을 논리 블록으로 분할하려는 시도

    • 섹션 헤더를 식별합니다

    • 합격/불합격 지표 감지

    • 알려지지 않은 형식에 대해서도 합리적인 출력 구조를 제공합니다.

  2. 유연한 통합

    • 임의의 셸 명령으로 작동합니다

    • 특정 형식 요구 사항 없음

    • act , Docker 및 사용자 정의 스크립트와 같은 도구와의 통합에 적합합니다.

  3. 보안 기능

    • 유해한 작업을 방지하기 위한 명령 검증

    • 필요한 경우 특정 승격된 권한을 허용하도록 구성할 수 있습니다.

출력 형식

테스트 러너는 완전한 테스트 출력을 보존하면서 구조화된 출력을 생성합니다.

interface TestResult {
  name: string;
  passed: boolean;
  output: string[];
  rawOutput?: string;  // Complete unprocessed output
}

interface TestSummary {
  total: number;
  passed: number;
  failed: number;
  duration?: number;
}

interface ParsedResults {
  framework: string;
  tests: TestResult[];
  summary: TestSummary;
  rawOutput: string;  // Complete command output
}

결과는 지정된 출력 디렉토리에 저장됩니다.

  • test_output.log : 원시 테스트 출력

  • test_errors.log : 오류 메시지가 있는 경우

  • test_results.json : 구조화된 테스트 결과

  • summary.txt : 사람이 읽을 수 있는 요약

개발

설정

  1. 저장소를 복제합니다

  2. 종속성 설치:

    npm install
  3. 프로젝트를 빌드하세요:

    npm run build

테스트 실행

npm test

테스트 모음에는 지원되는 모든 프레임워크에 대한 테스트가 포함되어 있으며 성공한 테스트 시나리오와 실패한 테스트 시나리오를 모두 검증합니다.

CI/CD

이 프로젝트에서는 지속적인 통합을 위해 GitHub Actions를 사용합니다.

  • Node.js 18.x 및 20.x에서 자동화된 테스트

  • 아티팩트로 업로드된 테스트 결과

  • 자동 종속성 업데이트를 위해 구성된 Dependabot

기여하다

  1. 저장소를 포크하세요

  2. 기능 브랜치를 생성하세요

  3. 변경 사항을 커밋하세요

  4. 지점으로 밀어 넣기

  5. 풀 리퀘스트 만들기

특허

이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.

Available Tools

1 tool
run_testsC

Run tests and capture output

ParametersJSON Schema
NameRequiredDescriptionDefault
commandYesTest command to execute (e.g., "bats tests/*.bats")
envNoEnvironment variables for test execution
frameworkYesTesting framework being used
outputDirNoDirectory to store test results
securityOptionsNoSecurity options for command execution
timeoutNoTest execution timeout in milliseconds (default: 300000)
workingDirYesWorking directory for test execution

TDQS

C2.7/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'capture output' but doesn't describe output format, error handling, side effects, or security implications. The description doesn't contradict annotations (none exist), but fails to disclose important behavioral traits.

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

Conciseness5/5

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

The description is extremely concise at just four words, front-loaded with the core action and outcome. Every word earns its place with zero redundancy or unnecessary elaboration.

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?

For a complex tool with 7 parameters, nested objects, no annotations, and no output schema, the description is insufficient. It doesn't explain return values, error conditions, security considerations, or typical usage patterns that would help an agent understand this execution tool's behavior.

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?

Schema description coverage is 100%, providing detailed parameter documentation. The description adds no additional parameter semantics beyond the schema's comprehensive coverage, so it meets the baseline of 3 for high schema coverage without compensating value.

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

Purpose3/5

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

The description 'Run tests and capture output' clearly states the action (run tests) and outcome (capture output), but lacks specificity about what types of tests or how they're executed. It doesn't distinguish from siblings (none exist), but remains somewhat vague about scope and implementation details.

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 no guidance on when to use this tool versus alternatives, prerequisites, or typical scenarios. With no sibling tools mentioned, differentiation isn't needed, but there's still no context about appropriate use cases or limitations.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev1.0.0
    • First observedrun_tests

TDQS

C2.9/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The tool's purpose is clearly defined as running tests and capturing output, making it distinct by default.

Naming Consistency5/5

The single tool name 'run_tests' follows a clear verb_noun pattern, which is consistent within this minimal set. There are no other tools to compare against, so no inconsistency can arise.

Tool Count2/5

A single tool is generally too few for most server purposes, as it limits functionality and flexibility. For a test runner, one tool might cover basic execution but lacks operations like listing tests, filtering, or managing test suites, making it feel thin and under-scoped.

Completeness2/5

The tool surface is severely incomplete for a test runner domain. It only provides execution without supporting operations such as listing available tests, retrieving results, configuring test runs, or handling test environments, leading to significant gaps that could cause agent failures.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Related MCP Connectors

  • Direct access to Cypress tests results and accessibility reports in your AI workflow.

  • Approved test intent, reviewed Playwright automation and run evidence, inside your editor.

  • Manage test suites, run tests, view results, and automate QA workflows via AI with testRigor.

  • Run, debug, and triage tests from your IDE using natural language, no dashboard switching, no manual data transfers. The TestMu AI (formerly LambdaTest) MCP Server is a single remote server exposing four tool suites: HyperExecute — analyze your project, generate YAML configs and test runner commands, then monitor jobs and sessions. Automation — pull a TestID's details plus command, network, and console logs into one chat for instant root-cause analysis. Includes mobile app upload. SmartUI — explain pixel, layout, DOM, and perceptual changes in a visual regression run, with context-aware React/HTML/CSS fixes. Accessibility — audit any public URL or a local React app against WCAG and get ready-to-apply remediation steps. Connects over https://mcp.lambdatest.com/mcp using OAuth 2.1 — no API keys in your config. One-click install in Cursor; works with Claude, GitHub Copilot, Cline, and any MCP client. Tests execute on the TestMu AI cloud: 3,000+ browsers and 10,000+ real devices.

Related MCP Servers

  • A
    license
    Not graded
    quality
    B
    maintenance
    Facilitates isolated code execution within Docker containers, enabling secure multi-language script execution and integration with language models like Claude via the Model Context Protocol.
    5
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Provides a standardized interface for interacting with Rocketlane's tools and services through the Model Context Protocol, enabling unified API access.
    1
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Provides a standardized interface for interacting with Neon's tools and services through a unified API via the Model Context Protocol.
    MIT