home / skills / jeongheonk / c-sharp-custom-marketplace / csharp-test-develop

csharp-test-develop skill

/skills/csharp-test-develop

This skill analyzes legacy C# code to generate unit and integration tests using xUnit, Moq, and FluentAssertions for improved reliability.

npx playbooks add skill jeongheonk/c-sharp-custom-marketplace --skill csharp-test-develop

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
6.8 KB
---
name: csharp-test-develop
description: C#/.NET 테스트 코드 작성. 기존 코드에 대한 단위/통합 테스트를 xUnit, Moq, FluentAssertions 기반으로 생성. 서브에이전트에 위임.
user-invocable: true
context: current
model: opus
argument-hint: "<class-or-file-path>"
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash(node *)
  - Bash(dotnet test *)
  - Glob
  - Grep
  - Task
---

# C# Test Develop

기존 C# 코드에 대한 테스트 코드를 작성하는 스킬. TDD 워크플로우 없이 구현된 코드를 분석하고 테스트를 생성합니다.

## Overview

```
┌─────────────────────────────────────────────────────────────┐
│  csharp-test-develop (Orchestrator)                         │
│  ├── Phase 0: 환경 감지 ──── test-detector.js 재사용        │
│  ├── Phase 1: 분석 ───────── 대상 코드 → 테스트 시나리오   │
│  └── Phase 2: 검증 ───────── dotnet test 통과 확인          │
├─────────────────────────────────────────────────────────────┤
│  Sub-agent (Executor)                                        │
│  └── 테스트 코드 작성 ────── references/csharp-test-patterns│
│                                                             │
│  ※ csharp-best-practices 규칙 참조 가능                    │
└─────────────────────────────────────────────────────────────┘
```

## csharp-tdd-develop과의 차이

| 구분 | csharp-tdd-develop | csharp-test-develop |
|------|-------------------|---------------------|
| 목적 | 새 기능 TDD 개발 | 기존 코드에 테스트 추가 |
| 워크플로우 | Red-Green-Refactor | 분석 → 테스트 작성 → 검증 |
| 구현 코드 | 테스트 후 작성 | 이미 존재 |
| 시점 | 개발 시작 | 개발 후 / 레거시 코드 |

---

## Workflow

### Phase 0: 환경 확인

.csproj 파일에서 테스트 환경 자동 감지.

```bash
# csharp-tdd-develop의 test-detector.js 재사용
node skills/csharp-tdd-develop/scripts/test-detector.js --detect
```

미설치 시 필요한 패키지 안내 후 중단.

---

### Phase 1: 분석

대상 코드를 읽고 테스트 시나리오를 도출합니다.

**동작:**
1. 대상 파일/클래스 읽기
2. public 메서드 목록 추출
3. 의존성 분석 (DI 인터페이스)
4. 테스트 시나리오 도출 (정상/예외/엣지 케이스)
5. 테스트 파일 경로 결정

**Output:**
```markdown
## 분석 결과

### 대상 클래스
- 이름: OrderService
- 경로: src/Services/OrderService.cs
- 의존성: IOrderRepository, IPaymentGateway, ILogger<OrderService>

### 테스트 시나리오
1. CreateOrderAsync — 유효한 주문 생성 성공
2. CreateOrderAsync — 재고 부족 시 예외 발생
3. CreateOrderAsync — 결제 실패 시 롤백
4. GetOrderByIdAsync — 존재하는 주문 반환
5. GetOrderByIdAsync — 존재하지 않는 주문 null 반환
6. CancelOrderAsync — 이미 취소된 주문 예외

### 테스트 파일
- 경로: tests/UnitTests/Services/OrderServiceTests.cs
```

---

### Phase 2: 테스트 작성 (서브에이전트 위임)

**Task tool로 위임:**
```
Task({
  subagent_type: "general-purpose",
  prompt: `
기존 코드에 대한 단위 테스트를 작성하세요.
SOLID 원칙, GoF 디자인 패턴, Modern C# 12/13 기능을 적용하세요.

## 대상
- 클래스: OrderService
- 경로: src/Services/OrderService.cs
- 테스트 파일: tests/UnitTests/Services/OrderServiceTests.cs

## 테스트 시나리오
1. CreateOrderAsync — 유효한 주문 생성 성공
2. CreateOrderAsync — 재고 부족 시 예외 발생
...

## 테스트 패턴 (필수 적용)
- AAA Pattern (Arrange-Act-Assert)
- 네이밍: Method_Scenario_ExpectedBehavior
- Moq로 의존성 Mock
- FluentAssertions 사용 (설치된 경우)
- xUnit Theory/InlineData (매개변수화 테스트)

## 지침
1. references/csharp-test-patterns.md 패턴 적용
2. 테스트 실행하여 **통과 확인** (dotnet test)
3. 테스트 결과 리포트
`
})
```

---

### Phase 3: 검증

- agent 응답에서 테스트 통과 확인
- 실패 시 수정 요청 (최대 3회)
- 커버리지 리포트 출력 (coverlet 설치 시)

---

## 현재 전달받은 인자

**ARGUMENTS**: $ARGUMENTS

## 실행 지시

위 ARGUMENTS가 테스트를 작성할 대상 클래스/파일 설명입니다.

**ARGUMENTS가 비어있으면** 사용자에게 테스트 대상을 질문하세요.

**호출 예시:**
- `/csharp-test-develop src/Services/UserService.cs` → 해당 파일 테스트 작성
- `/csharp-test-develop OrderService` → OrderService 클래스 찾아서 테스트 작성

---

## 실행 예시

### 요청
"OrderService에 대한 단위 테스트 작성해줘"

### 실행 흐름

```markdown
## Phase 0: 환경 확인
Runner: xUnit ✓ | FluentAssertions: YES ✓ | Moq: YES ✓

---

## Phase 1: 분석
- 클래스: OrderService
- public 메서드 3개
- 의존성 3개 (모두 인터페이스)
- 시나리오 6개 도출

---

## Phase 2: 테스트 작성
→ 서브에이전트 호출
← 테스트 파일 생성, 모든 테스트 통과 ✅

---

## 완료!
- tests/UnitTests/Services/OrderServiceTests.cs (6 tests)
```

---

## 테스트 파일 경로 규칙

**경로 결정 기준**: Repository/Database 접근 코드 → `IntegrationTests`, 나머지 → `UnitTests`

| 소스 위치 | 테스트 위치 |
|-----------|------------|
| `src/Services/UserService.cs` | `tests/UnitTests/Services/UserServiceTests.cs` |
| `src/ViewModels/MainViewModel.cs` | `tests/UnitTests/ViewModels/MainViewModelTests.cs` |
| `src/Repositories/UserRepository.cs` | `tests/IntegrationTests/Repositories/UserRepositoryTests.cs` |

---

## Error Handling

| 상황 | 처리 |
|------|------|
| 테스트 러너 미설치 | 설치 명령어 출력 후 중단 |
| 대상 파일 미발견 | 사용자에게 경로 확인 요청 |
| 테스트 실패 | 최대 3회 수정 시도 후 사용자에게 도움 요청 |

---

## 위임 구조

```
csharp-test-develop (Orchestrator)
    │
    └── general-purpose sub-agent
            │
            └── 참조 가능 리소스:
                  ├── csharp-best-practices/rules/ ← C# 12 규칙 (필요시 Read)
                  └── references/
                        └── csharp-test-patterns.md ← 테스트 패턴 (필요시 Read)
```

---

## Resources

### references/
- `csharp-test-patterns.md`: C# 테스트 패턴 가이드 (AAA, Moq, FluentAssertions 등)

Overview

This skill generates unit and integration tests for existing C#/.NET code using xUnit, Moq, and FluentAssertions. It analyzes target files, derives test scenarios, delegates test code generation to a sub-agent, and verifies test execution with dotnet test. It focuses on legacy or post-implementation code rather than TDD workflows.

How this skill works

The orchestrator detects the project test environment from csproj and installed packages, then parses target classes to extract public methods and dependencies. It produces a set of normal, edge, and exception scenarios and decides test file placement (UnitTests vs IntegrationTests). Test creation is delegated to a general-purpose sub-agent that applies AAA, Moq, FluentAssertions, and xUnit conventions. Finally, it runs dotnet test and reports pass/fail and coverage if available.

When to use it

  • Add tests to existing or legacy C# code that lacks coverage.
  • Generate unit tests quickly for services, viewmodels, or repositories.
  • Validate behavior after refactors or bug fixes.
  • Create parameterized scenarios using xUnit Theory/InlineData.
  • Enforce consistent test patterns across a team codebase.

Best practices

  • Provide the target file path or class name as the argument to avoid ambiguity.
  • Prefer unit tests for classes with mocked dependencies and integration tests for repository/DB access.
  • Use clear naming: Method_Scenario_ExpectedBehavior and AAA structure.
  • Limit sub-agent modification attempts to three; review failures manually if needed.
  • Run dotnet test locally and include coverlet for coverage reports when required.

Example use cases

  • Generate tests for src/Services/OrderService.cs to cover Create/Get/Cancel flows with mocked IOrderRepository and IPaymentGateway.
  • Create unit tests for ViewModel commands in a WPF project to verify property changes and command execution.
  • Convert undocumented methods in a legacy repository into unit-tested behaviors before a refactor.
  • Add parameterized edge-case tests for input validation using xUnit Theory and InlineData.
  • Produce integration tests for repository classes that access a real or in-memory database.

FAQ

What input does the skill need to start?

Provide a file path or class name (e.g., src/Services/OrderService.cs or OrderService). If no argument is given, the skill will ask which target to test.

Which testing frameworks are supported?

Primary output uses xUnit, Moq for mocking, and FluentAssertions when available. The skill checks for installed packages and prompts for installation if missing.