test-intelligence-mcp

AI 코딩 에이전트(Claude Code, Claude Desktop 또는 기타 MCP 클라이언트)가 Python 저장소의 테스트 상태(커버리지, 불안정한 테스트, ML 기반 풀 리퀘스트 위험 예측)를 분석할 수 있도록 하는 MCP(Model Context Protocol) 서버입니다.

상태: 활발히 개발 중입니다. 이 README는 각 마일스톤에 따라 업데이트됩니다. 현재 실제 구현된 기능과 아직 개발 중인 기능은 아래 빌드 상태를 참조하세요.

기능

Python 저장소를 지정하고 MCP 인식 에이전트와 자연어 대화를 통해 다음을 수행할 수 있습니다.

• 저장소의 테스트 스위트를 커버리지와 함께 실행하고 파일별 실제 수치를 반환받습니다(analyze_coverage)

• 테스트 스위트를 여러 번 실행하고 순서 의존적 또는 환경 의존적 실패와는 별개로 진정으로 불안정한 테스트를 탐지합니다(detect_flaky_tests)

• 테스트 실행 결과를 Postgres에 저장하여 시간 경과에 따른 기록을 구축합니다(record_test_run)

• 저장된 기록을 다시 조회합니다(get_test_history)

• 누적된 실행 기록에 대해 그래디언트 부스팅 분류기를 학습시켜 풀 리퀘스트의 어떤 파일이 테스트를 실패시킬 가능성이 있는지 예측합니다(train_risk_model)

• 브랜치를 기준 ref와 비교하고 변경된 각 파일에 대한 순위가 매겨진 위험 점수를 얻습니다(predict_pr_risk)

모든 기능은 실제 서브프로세스 테스트 실행과 실제 coverage.json 파싱을 기반으로 합니다. 터미널 출력을 스크래핑하거나 숫자를 조작하지 않습니다.

MCP를 사용하는 이유

MCP는 (Anthropic이 오픈소스로 공개했으며 현재 널리 채택된) 프로토콜로, AI 에이전트가 표준 JSON-RPC 전송(로컬에서는 stdio, 원격에서는 HTTP/SSE)을 통해 별도의 서버 프로세스가 노출하는 도구를 발견하고 호출할 수 있게 합니다. 맞춤형 API를 직접 개발하고 에이전트의 시스템 프롬프트에 이를 알릴 필요 없이, 타입이 지정된 Python 함수를 "도구"로 노출하기만 하면 클라이언트가 자동으로 이름, 인수 스키마, 독스트링을 발견하고 대화 중에 호출합니다. 이 프로젝트는 공식 MCP 사양 위에 구축된 사용하기 쉬운 Python SDK인 FastMCP 를 사용합니다. 일반적인 타입 지정 함수에 @mcp.tool()을 추가하는 것만으로 도구를 노출할 수 있습니다.

기술 스택

저장소 구조

test-intelligence-mcp/
  src/test_intelligence/
    server.py       # FastMCP server + tool registration
    config.py        # typed settings, loaded from .env
    safety.py         # repo-path allowlist gate (see Safety below)
    paths.py            # cross-platform file-path normalization
    runners/               # pytest/coverage execution, JUnit + coverage.json parsing
    flaky/                   # multi-run comparison logic, order/seed control
    ml/                        # features.py, synthetic.py, training.py, prediction.py, model_store.py
    db/                        # SQLAlchemy models, session, query helpers
    git/                        # commit/branch metadata (repo_info.py), diff stats (diff.py)
  tests/                       # tests for THIS project's own code
    fixtures/                  # tiny throwaway repos the runner tests execute for real
  scripts/
    ci_report.py         # flaky-check + coverage summary, invoked by CI (see below)
  alembic/             # migration scripts
  .github/workflows/
    ci.yml              # runs on every PR — see Continuous Integration below
  docker-compose.yml  # local Postgres
  pyproject.toml
  .env.example

설정

1. 사전 요구 사항

• Python 3.11+

• uv — pip + venv + virtualenv를 대체하는 빠르고 현대적인 도구로, 여기서는 종속성 관리 및 명령 실행에 사용됩니다. Windows: winget install -e --id astral-sh.uv.

• Docker Desktop — docker-compose를 통해 로컬에서 Postgres를 실행하는 데 사용되므로 머신에 Postgres를 설치할 필요가 없습니다. Windows: winget install -e --id Docker.DockerDesktop.

2. 종속성 설치

uv sync

uv sync는 pyproject.toml을 읽고, 잠긴 종속성 세트를 해결하여(uv.lock 작성/사용) .venv/를 생성합니다. 이는 새로운 virtualenv 내에서 pip install -r requirements.txt를 실행하는 uv 버전이지만, 더 빠르고 머신 간에 재현 가능합니다.

3. Postgres 시작

docker-compose up -d

이 명령은 docker-compose.yml에 정의된 Postgres 16 컨테이너를 시작하고, localhost:5433에 해당 파일에 포함된 자격 증명으로 노출합니다. (Postgres 기본값인 5432 대신 5433 포트를 사용하여 이미 Postgres가 설치된 경우 충돌을 방지합니다. 자세한 내용은 docker-compose.yml 참조.) -d는 분리 모드(백그라운드)로 실행합니다. 정상 작동 여부는 다음으로 확인합니다:

docker-compose ps

상태가 healthy인 test-intelligence-postgres가 표시되어야 합니다.

4. 환경 구성

cp .env.example .env

.env.example의 기본값은 이미 docker-compose.yml의 자격 증명과 일치하므로, 로컬 개발의 경우 일반적으로 TI_ALLOWED_REPO_ROOTS를 제외하고는 아무것도 변경할 필요가 없습니다(아래 안전 참조).

5. 데이터베이스 마이그레이션 적용

uv run alembic upgrade head

Alembic은 alembic/versions/ 아래의 모든 마이그레이션 스크립트를 순서대로 재생하여 데이터베이스 스키마를 최신 버전으로 업데이트합니다. (현재 모델 코드에 따라 일치하는 테이블만 찍어낼 수 있고 과거 상태에 대한 기억이 없는) Base.metadata.create_all()과 달리, Alembic은 스키마 기록을 정렬된 스크립트 체인으로 추적하므로 변경 사항을 git에서 검토할 수 있고 되돌릴 수 있으며(alembic downgrade), dev, CI, prod에서 동일하게 적용됩니다.

6. MCP 클라이언트에 등록

Claude Code

claude mcp add test-intelligence -- uv run --directory "C:\path\to\test-intelligence-mcp" test-intelligence-mcp

--directory를 사용하면 (단순히 claude mcp add를 실행한 디렉토리에 의존하는 대신) Claude Code의 프로세스가 나중에 서버를 시작하는 위치에 관계없이 등록이 작동합니다. 이는 서버가 시작 시 작업 디렉토리를 기준으로 .env를 읽기 때문에 중요합니다.

이 명령은 서버를 로컬 Claude Code 구성에 범위가 지정된 stdio-전송 MCP 서버로 등록합니다. claude mcp list로 연결을 확인한 다음 새 Claude Code 세션을 시작하고(이미 실행 중인 세션은 시작 후 등록된 서버를 인식하지 못함) 사용 가능한 도구를 나열하도록 요청하세요.

Claude Desktop

claude_desktop_config.json에 추가합니다 (Windows: %APPDATA%\Claude\claude_desktop_config.json):

{
  "mcpServers": {
    "test-intelligence": {
      "command": "uv",
      "args": ["--directory", "C:\\path\\to\\test-intelligence-mcp", "run", "test-intelligence-mcp"]
    }
  }
}

Claude Desktop을 다시 시작하면 🔨 도구 아이콘 아래에 여섯 개의 도구가 나타납니다.

안전

이 도구들은 대상 저장소의 실제 테스트 스위트, 즉 임의의 Python 코드를 서브프로세스로 실행하기 때문에 두 가지 안전 장치가 무조건 적용됩니다.

• 경로 허용 목록: 모든 repo_path 인수는 절대 경로로 확인된 후 .env의 TI_ALLOWED_REPO_ROOTS(허용된 기본 디렉토리의 쉼표로 구분된 목록)와 비교하여 검사됩니다. 허용 목록 외부의 경로는 서브프로세스가 실행되기 전에 거부됩니다.

• 서브프로세스 타임아웃: 모든 subprocess 호출(pytest 실행, git 명령)에는 하드 타임아웃(.env의 TI_SUBPROCESS_TIMEOUT_SECONDS, 기본값 300초)이 있어 중단되거나 무한 루프에 빠진 스위트가 서버를 무기한 차단할 수 없습니다.

사용 예시

analyze_coverage

MCP 인식 에이전트에게 "Run analyze_coverage on C:\path\to\some-repo" 와 같이 요청하세요. 도구는 해당 저장소의 테스트 스위트를 커버리지와 함께 실행하고(자체 .venv/venv가 있으면 사용하고, 없으면 이 서버의 인터프리터로 대체) 다음을 반환합니다:

{
  "status": "ok",
  "tests_passed": true,
  "overall_coverage_percent": 87.5,
  "total_statements": 120,
  "total_covered_lines": 105,
  "total_uncovered_lines": 15,
  "files": [
    {
      "file": "pkg/calculator.py",
      "coverage_percent": 80.0,
      "num_statements": 10,
      "covered_lines": 8,
      "uncovered_line_count": 2,
      "uncovered_lines": [12, 13]
    }
  ]
}

files는 커버리지가 낮은 순서로 정렬되므로 에이전트가 가장 테스트가 필요한 파일을 즉시 식별할 수 있습니다. 대상 저장소에 해결된 Python 환경에 pytest와 pytest-cov가 설치되어 있어야 합니다.

record_test_run + get_test_history

"Record a test run for C:\path\to\some-repo, then show me the history for pkg/calculator.py" — 첫 번째 호출은 pytest의 --junitxml 출력을 통해 스위트를 한 번 실행하고(따라서 대상 저장소에 pytest만 있으면 되고 플러그인은 필요 없음), Repository/TestRun/TestResult 행 세트를 Postgres에 저장하며, 실제 git 저장소인 경우 GitPython을 통해 대상 저장소의 현재 커밋 SHA와 브랜치로 실행에 태그를 지정합니다:

{
  "status": "ok",
  "run_id": 3,
  "repo_id": 1,
  "commit_sha": "a1b2c3d...",
  "branch": "main",
  "duration_seconds": 0.52,
  "total_tests": 3,
  "passed_count": 1,
  "failed_count": 1,
  "skipped_count": 1
}

get_test_history는 record_test_run이 이미 작성한 행만 읽습니다. 자체적으로 실행을 트리거하지 않으며, 이 서버가 기록한 모든 저장소를 대상으로 쿼리하며(repo_path 인수 없음), 선택적으로 하나의 file_path로 필터링할 수 있습니다:

{
  "status": "ok",
  "count": 2,
  "history": [
    {
      "repo_name": "C:\\path\\to\\some-repo",
      "run_id": 3,
      "commit_sha": "a1b2c3d...",
      "branch": "main",
      "started_at": "2026-08-16T00:20:11+00:00",
      "node_id": "tests/test_calculator.py::test_divide",
      "file_path": "tests/test_calculator.py",
      "outcome": "passed",
      "duration_seconds": 0.001,
      "error_message": null
    }
  ]
}

detect_flaky_tests

"Run detect_flaky_tests on C:\path\to\some-repo with 5 runs" — 알려진 테스트 순서 무작위화 플러그인(pytest-randomly, pytest-random-order)을 명시적으로 비활성화한 상태에서 스위트를 runs번 실행하므로 테스트 순서는 모든 실행에서 동일합니다. 이는 테스트가 실행 간에 서로 다른 결과를 내는 유일한 가능한 설명으로 진정한 비결정론(타이밍, 공유 상태, 테스트 대상 코드의 시드되지 않은 무작위성)을 분리합니다. 순서 섞기 플러그인이 있으면 순서 의존적 실패와 실제 불안정성을 구분할 수 없기 때문입니다. 대규모 스위트에서 5번 이상의 순차 실행은 시간이 걸릴 수 있으므로 진행 상황은 MCP 진행 알림(이를 지원하는 클라이언트에 표시됨)을 통해 실시간으로 스트리밍됩니다:

{
  "status": "ok",
  "repo_id": 2,
  "runs_requested": 5,
  "runs_completed": 5,
  "total_tests_observed": 2,
  "flaky_test_count": 1,
  "flaky_tests": [
    {
      "node_id": "tests/test_flaky.py::test_alternates",
      "runs_observed": 5,
      "inconsistency_count": 2,
      "flakiness_rate": 0.4,
      "outcomes": ["passed", "failed", "passed", "failed", "passed"],
      "majority_outcome": "passed"
    }
  ],
  "run_failures": []
}

감지된 불안정한 테스트는 flaky_reports 테이블에도 저장됩니다.

train_risk_model

"Train the risk model" — 파일당 10가지 특징(변경량, 과거 실패 횟수, 현재 커버리지, 파일을 건드리는 테스트 수, 마지막 수정 후 일수, 고유 작성자 수, 파일 크기, 순환 복잡도 — 학습 데이터 출처는 ML 모델의 콜드 스타트 전략 참조)을 기반으로 "이 파일이 변경된 후 테스트가 실패할까?"를 예측하도록 GradientBoostingClassifier를 학습시키고, 분할된 테스트 세트에서 평가한 후 정직하게 보고합니다:

{
  "status": "ok",
  "model_path": "models/risk_model.joblib",
  "real_sample_count": 0,
  "synthetic_sample_count": 500,
  "total_sample_count": 500,
  "test_set_size": 125,
  "metrics": {
    "accuracy": 0.6,
    "precision": 0.5962,
    "recall": 0.5167,
    "f1": 0.5536
  },
  "caveat": "Only 0 real training example(s) recorded so far (via record_test_run) — this training run is dominated by synthetic, artificially-generated bootstrap data. These metrics describe how well the model fits that synthetic relationship, NOT real predictive power on an actual repository. Keep calling record_test_run on real repos, then retrain, before trusting these numbers for anything beyond confirming the training pipeline itself works."
}

caveat 필드는 real_sample_count가 실제 임계값(30, ml/training.py 참조)을 초과할 때만 사라집니다. 이 도구는 합성 데이터가 지배적인 메트릭을 실제로 검증된 것처럼 제시하지 않습니다.

(나머지 도구는 마일스톤별로 추가될 예정입니다. 빌드 상태 참조.)

ML 모델의 콜드 스타트 전략

train_risk_model에는 레이블이 지정된 예제, 즉 "파일 변경에 대한 이러한 특징이 주어졌을 때, 해당 파일과 관련된 테스트가 이후에 실패했는가?"가 필요합니다. 새로 설정된 서버에서는 기록된 실행이 없으므로 학습할 기록이 없습니다. ML 코드를 작성하기 전에 세 가지 옵션이 고려되었습니다.

1. 실제 오픈 소스 저장소의 git/CI 기록 재생. 실제 프로젝트를 복제하고, 커밋을 탐색하며, 각각을 체크아웃하고, 해당 시점의 종속성을 설치하고, 스위트를 실행하여 실제 특징과 실제 레이블을 추출합니다. 현실적인 데이터이지만 안정적으로 구축하기에는 비용이 많이 들고 취약합니다. 종속성 설치는 수년간의 기록에서 자주 중단되며(더 이상 사용되지 않는 패키지, Python 버전 변경), 전체 기록 체크아웃은 느리고, 이 프로젝트 자체 CI에 (특정 시점의 특정 저장소라는) 하드 외부 종속성을 추가하여 매 실행마다 재현해야 합니다.

2. 이 프로젝트 자체 커밋 재생. 동일한 아이디어이지만 범위가 더 작습니다. 핵심 비용 문제를 피하지 못하며, 이 프로젝트 자체의 기록은 범용 위험 모델이 일반화해야 할 파일 변경 패턴의 폭을 대표하기에는 너무 짧고 좁습니다.

3. 합성 데이터 생성 (선택됨). 그럴듯한 분포에서 특징 벡터를 추출하고 의도적으로 설계된 도메인 기반 생성 규칙(변경량이 많을수록 + 과거 실패가 많을수록 + 커버리지가 낮을수록 + 복잡도가 높을수록 → 실패 확률 증가, 노이즈 포함)에서 레이블을 도출합니다. 동전 던지기가 아닙니다. 빠르고, 완전히 재현 가능하며, 외부 저장소가 필요 없고, 오늘 당장 전체 파이프라인(특징 추출 → 학습 → 평가)을 정직하게 실행할 수 있을 만큼 충분합니다.

정직한 절충안: 순수하게 합성 데이터로 학습된 모델은 그럴듯한 위험 관계의 형태를 학습했을 뿐, 실제 관계는 아닙니다. 보류된 합성 데이터에 대한 메트릭은 합리적으로 보이지만(정확도 ~0.6, ROC-AUC ~0.67 — tests/ml/test_synthetic.py 참조), 이는 파이프라인이 작동한다는 것만 증명할 뿐 실제 저장소에 대해 무엇인가를 예측한다는 것은 증명하지 않습니다. train_risk_model은 실제 예제가 존재하는 즉시 이를 혼합하고(record_test_run → file_changes 행 참조) 항상 실제/합성 분할과 실제 데이터가 신뢰하기에 너무 적은 경우 명시적인 경고를 보고합니다. 합성 데이터에서 파생된 수치를 검증된 것으로 제시하지 않습니다.

실제 예제의 출처: record_test_run은 각 실행 후 실제 git diff(HEAD~1..HEAD)를 계산하고 변경된 파일당 하나의 file_changes 행을 작성하며, tests_failed_after = "이 실행에서 어느 테스트라도 실패했는가"로 레이블을 붙입니다. 이는 변경된 모든 파일에 적용되며, 파일별 귀속이 아닙니다. 이는 의도적인 선택입니다: 실패를 야기한 특정 파일에 귀속시키려면 커버리지 기반 추적(어느 테스트가 어떤 소스 라인을 실행했는지)이 필요하지만, 이 프로젝트는 그렇게 하지 않습니다. 더 거친 신호는 솔직히 상관관계("이 파일은 무언가를 망가뜨린 커밋의 일부였다")에 가깝고 인과관계는 아닙니다. 전체 추론은 runners/record_run.py의 주석을 참조하세요. 파일 경로 문자열 일치 휴리스틱이 더 정밀해 보이지만 실제로는 더 좁고 오해를 불러일으킬 수 있는 이유도 포함되어 있습니다.

과거 특성 추출(실제 훈련 예제에 사용됨)은 각 기록된 실행의 타임스탬프와 커밋 "시점"의 git 히스토리를 읽습니다 — git log --before, git show <sha>:<path> — 파일의 현재 상태는 절대 읽지 않으므로, 모델이 예측 시점에 아직 존재하지 않았던 정보를 우연히 학습할 수 없습니다. coverage_percent는 과거에 재구성할 수 없는 유일한 특성입니다. 정확히 그 커밋에서 전체 스위트를 다시 실행해야 하기 때문입니다(훈련 예제당 비용이 너무 큼). 따라서 실제 과거 행에 대해 명시적인 "unknown" 센티널로 저장되며, 실시간 예측(predict_pr_risk, 아래 참조)에서만 새로 계산됩니다.

predict_pr_risk

"C:\path\to\some-repo의 PR 위험을 main에 대해 예측" — base_ref..HEAD를 diff하고(실제 git diff --numstat), 각 변경된 파일에 대해 실시간 특성을 추출하며(현재 작업 트리 상태, 그리고 실제 현재 커버리지를 위한 새로운 analyze_coverage 실행 — 과거 훈련 행이 받는 "unknown" 센티널이 아님), 각각을 훈련된 모델로 점수 매기고 위험이 가장 높은 순으로 정렬합니다:

{
  "status": "ok",
  "repo_id": 3,
  "base_ref": "0bcbeba860df0457c55ad3c1d3826ed5fd941506",
  "commit_sha": "8306f4598275f92907de89e1161f982772f3aac7",
  "model_trained_at": "2026-08-17T19:03:42.707577+00:00",
  "model_real_sample_count": 0,
  "predictions": [
    { "file": "tests/test_calculator.py", "predicted_risk_probability": 0.0743, "lines_added": 9, "lines_deleted": 1 },
    { "file": "pkg/calculator.py", "predicted_risk_probability": 0.0457, "lines_added": 7, "lines_deleted": 0 }
  ]
}

model_real_sample_count는 모델의 훈련 메타데이터에서 전달됩니다. 따라서 호출자는 별도의 조회 없이 이 예측이 합성 데이터 위주의 모델에서 나온 것인지(콜드 스타트 전략 참조) 한눈에 알 수 있습니다. train_risk_model이 최소 한 번 실행되어야 합니다(그렇지 않으면 no_trained_model 오류 발생) — 이 도구는 절대 부작용으로 암시적으로 모델을 훈련하지 않습니다. 모든 예측은 actual_outcome을 NULL로 남긴 채 risk_predictions에 저장되므로, 실제 저장소의 예측을 나중에 실제 발생한 결과와 대조할 수 있습니다. 해당 평가는 아직 구축되지 않았지만, 데이터는 처음부터 캡처되므로 스키마 변경 없이 추가할 수 있습니다.

지속적 통합 (GitHub Actions)

GitHub Actions는 GitHub에 직접 내장된 CI입니다: 워크플로우 — 하나의 YAML 파일, .github/workflows/ci.yml — 은 저장소 이벤트(여기서는 풀 리퀘스트 열기/업데이트 또는 main에 푸시)에 응답하여 자동으로 실행되는 작업을 설명합니다. 각 작업은 새롭고 일회용 가상 머신("러너")에서 실행됩니다. 명시적으로 캐시되거나 업로드된 것을 제외하고는 실행 간에 아무것도 유지되지 않습니다. 각 작업은 단계의 시퀀스이며, 각 단계는 셸 명령어 또는 재사용 가능한 액션(다른 사람이 게시한 패키지화된 단계, actions/checkout@v4처럼 참조됨)입니다.

이 프로젝트의 워크플로우는 프로젝트 자체를 종단 간 테스트하는 것입니다:

1. 저장소 체크아웃 및 uv + 종속성 설치 — 기여자가 로컬에서 설치하는 것과 동일한 도구.

2. Postgres를 서비스 컨테이너로 시작 — GitHub Actions가 작업과 함께 실행하는 두 번째 컨테이너로, 모든 단계에서 localhost:5433에 접근 가능하며, 로컬에서 docker-compose up -d와 정확히 동일하지만 Docker Desktop 대신 GitHub에서 관리합니다. 작업의 단계는 상태 확인이 통과할 때까지 시작되지 않습니다. 수동으로 "Postgres 대기" 폴링 루프가 필요 없습니다.

3. Alembic 마이그레이션 적용, 그런 다음 --cov-fail-under=$COVERAGE_THRESHOLD로 이 프로젝트 자체의 테스트 스위트 실행 — pytest-cov의 내장 게이트; 커버리지가 임계값(현재 80%, 실제 ~93% 아래에 여유 있음) 아래로 떨어지면 빌드가 바로 실패합니다.

4. 이 프로젝트 자체의 테스트에 대해 detect_flaky_tests 실행 — scripts/ci_report.py를 통해, 이 도구를 실제 MCP 계층(fastmcp.Client가 실제 서버 객체와 통신)을 통해 호출하며, 지름길을 사용하지 않습니다. 정보 제공용입니다. 빌드를 실패시키지 않으며, 커버리지만 실패시킵니다.

5. 두 보고서를 워크플로우 아티팩트로 업로드 (actions/upload-artifact) — 기본적으로 90일 동안 워크플로우 실행 페이지에서 다운로드 가능.

6. 작업 요약 작성 ($GITHUB_STEP_SUMMARY, 실행 페이지에 Markdown으로 렌더링) 및 PR 댓글로 게시 (actions/github-script, 실행에 내장된 GITHUB_TOKEN 사용 — 추가 비밀 필요 없음). 단계 요약은 항상 작동하는 폴백이며, 읽기 전용 토큰(댓글을 게시할 수 없음, GitHub 보안 제한 사항이며 이 워크플로우의 버그가 아님)을 받는 포크의 PR도 포함됩니다. 댓글 단계는 continue-on-error: true로 감싸져 있어 해당 제한이 전체 작업을 실패시키지 않고 정상적으로 저하됩니다.

이것이 실제로 실행되는 것을 보려면 프로젝트가 실제 GitHub 저장소에 있어야 하며 커밋이 푸시되어야 합니다. 이 로컬 빌드 프로세스에서는 아직 생성되지 않았습니다. 일단 존재하면: PR을 열면 Actions 탭(그리고 댓글이 도착하면 PR 자체)에서 실시간으로 실행되는 것을 볼 수 있습니다.

빌드 상태

이 프로젝트는 마일스톤별로 구축되며, 각 마일스톤은 다음으로 넘어가기 전에 작동이 확인됩니다.

• 마일스톤 1 — 프로젝트 스켈레톤, docker-compose Postgres, .env.example, 이 README

• 마일스톤 2 — 데이터베이스 계층 (SQLAlchemy 모델 + Alembic)

• 마일스톤 3 — FastMCP 서버 스켈레톤 (6개 도구 등록, 본문은 플레이스홀더)

• 마일스톤 4 — analyze_coverage

• 마일스톤 5 — record_test_run + get_test_history

• 마일스톤 6 — detect_flaky_tests

• 마일스톤 7 — ML 콜드 스타트 전략, 특성 추출, train_risk_model

• 마일스톤 8 — predict_pr_risk

• 마일스톤 9 — GitHub Actions CI (구축 + 로컬 확인; 실제 GitHub 저장소에서 라이브 PR 실행 대기 중)

• 마일스톤 10 — 최종 다듬기

이 프로젝트 자체 테스트 실행

uv sync --extra dev     # installs pytest-asyncio + ruff on top of the base deps
uv run pytest -v
uv run pytest --cov --cov-report=term-missing   # with coverage
uv run ruff check .                              # lint

DB 계층 테스트는 실제 일회용 Postgres 데이터베이스(test_intelligence_test, 자동 생성 및 제거)를 사용하고, 데이터베이스를 모킹하거나 create_all()을 사용하는 대신 실제 Alembic 마이그레이션을 실행합니다. 이는 CI가 Postgres 서비스 컨테이너(마일스톤 9)를 통해 사용하는 것과 동일한 접근 방식입니다. 자세한 내용은 tests/conftest.py를 참조하세요.

데이터 모델

Alembic 마이그레이션으로 관리되는 6개의 테이블:

• repositories — 추적된 저장소 (이름 + 로컬 경로 또는 원격 URL)

• test_runs — pytest 호출당 한 행 (저장소, 커밋 SHA, 브랜치, 타임스탬프, 기간, 통과/실패/건너뛰기 횟수)

• test_results — 실행 내 테스트 노드 ID당 한 행 (결과, 기간, 오류 메시지)

• file_changes — 실행에 대한 파일별 diff 통계 (추가/삭제된 라인 수, 변경 후 테스트 실패 여부)

• flaky_reports — 테스트 노드별 불안정성 요약 (관찰된 실행 횟수, 불일치 횟수, 탐지 타임스탬프)

• risk_predictions — 커밋에 대한 파일별 ML 위험 점수, 실제 결과가 알려지면 함께 저장 (모델의 오프라인 평가용)

라이선스

MIT