testing-strategy_skill

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