home / skills / partme-ai / full-stack-skills / test-writer

test-writer skill

safe

This skill helps you write comprehensive tests across unit, integration, and end-to-end levels with best practices and clear guidance.

npx playbooks add skill partme-ai/full-stack-skills --skill test-writer

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

Files (1)

SKILL.md

2.5 KB

---
name: test-writer
description: Provides comprehensive guidance for writing tests including test case creation, test structure, and testing best practices. Use when the user asks about writing tests, needs to create test cases, structure tests, or implement testing strategies.
---

# 测试编写技能

## 概述

本技能帮助您编写各种类型的测试，包括单元测试、集成测试和端到端测试。

**关键词**: 测试编写、单元测试、集成测试、端到端测试、测试用例、测试框架

## 核心功能

### 1. 单元测试编写

- 为函数和类编写单元测试
- 设计测试用例覆盖各种场景
- 使用 Mock 和 Stub 隔离依赖
- 确保测试的独立性和可重复性

### 2. 集成测试设计

- 编写模块间的集成测试
- 测试 API 接口和数据库交互
- 验证系统组件的协作
- 设计测试数据和测试环境

### 3. 端到端测试

- 编写完整的用户流程测试
- 测试关键业务场景
- 验证系统端到端的功能
- 使用自动化测试工具

### 4. 测试工具和框架

- 支持主流测试框架（JUnit, pytest, Jest 等）
- 生成测试报告和覆盖率报告
- 创建测试配置和测试环境
- 设计测试数据和 Fixture

## 使用指南

### 测试编写原则

1. **全面性**: 覆盖正常流程、边界情况和异常情况
2. **独立性**: 每个测试应独立运行，不依赖其他测试
3. **可重复性**: 测试结果应一致，不受环境影响
4. **清晰性**: 测试代码应清晰易懂
5. **快速性**: 测试应快速执行

### 测试用例设计

- **正常场景**: 测试正常的功能流程
- **边界情况**: 测试边界值和极限情况
- **异常情况**: 测试错误处理和异常情况
- **性能测试**: 测试性能和负载（如需要）

### 测试覆盖率

- 目标覆盖率: 80% 以上（根据项目需求）
- 关键路径: 100% 覆盖
- 边界情况: 重点覆盖
- 异常处理: 确保覆盖

## 输出格式

测试代码应包含：

- **测试文件**: 完整的测试代码文件
- **测试用例**: 清晰的测试用例和描述
- **测试数据**: 测试数据和 Fixture
- **测试配置**: 测试配置文件
- **测试报告**: 测试执行结果和覆盖率

## 最佳实践

- 使用 AAA 模式（Arrange-Act-Assert）
- 测试名称应描述测试内容
- 一个测试只测试一个功能点
- 使用 Mock 隔离外部依赖
- 保持测试代码简洁
- 定期运行测试，确保通过
- 关注测试覆盖率，但不盲目追求 100%

Overview

This skill provides practical, hands-on guidance for writing tests across unit, integration, and end-to-end levels. It helps you create clear test cases, structure test suites, and adopt testing strategies that improve reliability and maintainability. Use it to design test data, configure test environments, and choose appropriate frameworks and tools.

How this skill works

The skill inspects your testing requirements and recommends concrete test cases, file layouts, and fixtures tailored to the codebase and language (Python primary). It outlines test flows for normal, boundary, and error scenarios, suggests mocking and stubbing approaches to isolate dependencies, and recommends CI-friendly reporting and coverage settings. It also maps common frameworks and tools to tasks like API testing, database integration, and UI automation.

When to use it

When you need to create unit tests for functions and classes
When designing integration tests for services, APIs, or databases
When implementing end-to-end or UI automation for user flows
When you need test file layout, fixtures, or test data guidance
When preparing tests to run in CI with reports and coverage

Best practices

Follow Arrange-Act-Assert (AAA) and keep tests focused on one behavior
Make tests independent and reproducible; use fixtures and controlled test data
Use mocks/stubs to isolate external dependencies and speed tests
Name tests descriptively to document intent and expected outcome
Prioritize fast unit tests; run slower integration/e2e tests selectively
Track coverage for key paths (target ~80%), but focus on meaningful assertions

Example use cases

Generate pytest unit tests for a Python module with edge-case inputs and exception handling
Design integration tests that verify API endpoints and database transactions with test fixtures
Outline an end-to-end scenario for a user sign-up flow with automated UI steps and assertions
Create CI configuration snippets to run tests, produce JUnit-style reports, and upload coverage
Recommend mock strategies for third-party services so tests run offline and deterministically

FAQ

What coverage target should I aim for?

Aim for around 80% overall while ensuring 100% coverage on critical business paths; prioritize meaningful tests over raw percentage.

How do I keep tests fast and reliable?

Isolate slow or flaky external integrations with mocks, use in-memory test databases where appropriate, and run slow suites separately from quick unit tests.