home / skills / cacr92 / wereply / testing-strategy

testing-strategy skill

safe

This skill helps you design and enforce robust testing strategies for Rust and front-end components, guiding unit, integration, and TDD practices.

npx playbooks add skill cacr92/wereply --skill testing-strategy

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

Files (1)

SKILL.md

1.0 KB

---
name: testing-strategy
description: 当用户要求测试策略、单元/集成测试、TDD或测试覆盖率时使用。
---

# Testing Strategy Skill

## 适用范围
- Rust 单元/集成测试
- Tauri 命令与服务层测试
- 前端关键流程验证

## 关键规则（Critical Rules）
- 改动行为时优先补测试
- 异步测试使用 `#[tokio::test]`
- 只在存在脚本时执行前端测试命令

## Rust 测试模板
```rust
#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn should_sum_materials() {
        let total = 10.0 + 20.0;
        assert_eq!(total, 30.0);
    }
}
```

## 常用命令
```bash
cargo test
cargo test --all
```

## 前端验证
- 无测试脚本时，执行 `npm run lint` 并进行关键流程手测
- 重要交互建议补充可重复的操作步骤

## TDD 流程
1. 编写失败测试
2. 实现最小代码通过测试
3. 重构并保持测试通过

## 检查清单
- [ ] 行为改动有对应测试或明确手测步骤
- [ ] 异步测试使用 `tokio::test`
- [ ] 运行 `cargo test` 通过

Overview

This skill provides practical guidance for defining testing strategy, unit and integration tests, TDD workflows, and test coverage checks for a Python-centric project that includes Rust, Tauri, and front-end components. It focuses on actionable rules, common commands, and a concise checklist to ensure behavior changes are covered. Use it to decide what tests to add, how to run them, and when manual verification is acceptable.

How this skill works

The skill inspects the requested change or feature and recommends an appropriate test scope: unit tests for isolated logic, integration tests for cross-module behavior, and end-to-end checks for UI flows. It enforces critical rules such as adding tests when behavior changes and using async test patterns where relevant. For front-end changes, it detects whether test scripts exist and suggests linting plus manual verification when they do not.

When to use it

When modifying business logic or behavior to ensure regressions are prevented
When adding or changing async code that needs tokio-style async tests
When introducing new Tauri commands or service-layer behavior
When front-end flows change and you need repeatable verification or temporary manual steps
When implementing TDD: write failing tests, make them pass, then refactor

Best practices

Prioritize adding tests before or alongside behavior changes; if not possible, document manual verification steps
Use #[tokio::test] for asynchronous Rust tests to run async code reliably
Run cargo test (or cargo test --all) regularly in CI to catch regressions early
For front-end work, prefer repeatable automated checks; if tests are missing, run npm run lint and include clear manual test steps
Keep tests focused and fast: unit tests for logic, integration tests for boundaries, and minimal end-to-end tests for critical flows

Example use cases

A code change updates a message routing function: add unit tests that cover expected routes and edge cases
Adding a new Tauri command: write integration tests for service behavior and a small end-to-end check for the UI trigger
Converting synchronous code to async: add tokio-based tests that exercise concurrency paths
Front-end UI tweak without test scripts: run lint, add documented manual steps for QA, and plan automated test coverage later
Adopt TDD for a new feature: write failing tests first, implement minimal code to pass, then refactor while keeping tests green

FAQ

What if I change behavior but cannot add tests immediately?

Document explicit manual verification steps and create a ticket to add automated tests as soon as feasible; mark the change as high test debt priority.

How do I test async code?

Use an async test harness like #[tokio::test] in Rust or the equivalent in your language so async code runs within an executor during tests.