home / skills / d-oit / do-novelist-ai / qa-engineer

qa-engineer skill

/.opencode/skill/qa-engineer

This skill helps you implement comprehensive testing strategies and organize tests with robust mocking patterns for reliable TypeScript test suites.

npx playbooks add skill d-oit/do-novelist-ai --skill qa-engineer

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

Files (1)
SKILL.md
2.2 KB
---
name: qa-engineer
description:
  Define comprehensive testing strategies, write tests with proper naming
  conventions, organize tests by type, and implement mocking strategies. Use
  when creating tests, refactoring test suites, or improving test coverage.
---

# QA Engineer

Enforce comprehensive testing strategies, proper test organization, and
effective mocking patterns for reliable, maintainable test suites.

## Quick Reference

- **[Test Strategy](test-strategy.md)** - Overall testing approach
- **[Test Organization](test-organization.md)** - File and directory structure
- **[Mocking Strategy](mocking-strategy.md)** - Mocking best practices

## When to Use

- Writing new tests (unit, integration, E2E)
- Refactoring existing test suites
- Improving test coverage
- Creating testable code
- Debugging test failures
- Setting up test infrastructure
- Reviewing test quality

## Core Methodology

Comprehensive testing strategy covering unit, integration, and E2E testing with
proper mocking and organization.

**Key Principles**:

1. Test isolated behavior, not implementation details
2. Use AAA or Given-When-Then patterns
3. Mock only external dependencies
4. Reset mocks between tests
5. Test behavior, not private methods
6. Organize tests by type and feature

## Integration

- **typescript-guardian**: Type-safe test code
- **performance-engineer**: Performance test benchmarks
- **architecture-guardian**: Clean architecture tests
- **domain-expert**: Domain logic tests
- **security-specialist**: Security test coverage

## Best Practices

✓ Write descriptive test names ✓ Follow AAA or Given-When-Then patterns ✓ Mock
only external dependencies ✓ Test behavior, not implementation ✓ Use data-testid
for element selection ✓ Organize tests by type and feature ✓ Reset mocks between
tests ✗ Keep tests simple and focused

✗ Don't test private methods ✗ Don't be brittle to UI changes

---

## Content Modules

See detailed modules:

- **[Test Strategy](test-strategy.md)** - Testing methodology
- **[Test Organization](test-organization.md)** - File structure
- **[Mocking Strategy](mocking-strategy.md)** - Mocking best practices

Write comprehensive, reliable tests that catch bugs early and document expected
behavior.

Overview

This skill defines comprehensive testing strategies, organizes test suites by type and feature, and prescribes robust mocking patterns for TypeScript projects. It focuses on maintainable, readable tests that surface regressions early and document expected behavior. Use it to raise test quality across unit, integration, and end-to-end tests.

How this skill works

The skill inspects test scope and recommends an overall test strategy covering unit, integration, and E2E layers. It enforces naming conventions, file structure, and patterns such as AAA or Given-When-Then, while advising when and how to mock external dependencies. It also prescribes reset and isolation practices to keep suites deterministic and fast.

When to use it

  • Writing new tests for components, modules, or services
  • Refactoring or reorganizing an existing test suite
  • Improving test coverage and reliability
  • Designing code to be easily testable
  • Debugging intermittent or flaky test failures
  • Setting up CI test infrastructure or selecting tools

Best practices

  • Write descriptive, behavior-focused test names that state expected outcome
  • Follow AAA or Given-When-Then patterns for readable arrange-act-assert flow
  • Mock only external boundaries and avoid mocking implementation of SUT
  • Reset or restore mocks between tests and isolate global state
  • Organize tests by type (unit/integration/E2E) and by feature or domain
  • Prefer selectors like data-testid for stable UI tests and keep tests small

Example use cases

  • Create a unit test suite for a service with clear naming and mocked HTTP client
  • Refactor a monolithic tests directory into /unit, /integration, /e2e with shared helpers
  • Add integration tests to validate database interactions while mocking external APIs
  • Introduce mocking adapters to replace third-party SDKs in CI to avoid flakiness
  • Audit an existing suite to remove tests that assert private implementation details

FAQ

Should I mock everything to keep unit tests fast?

No. Mock external dependencies and network calls, but test internal behavior without over-mocking the system under test to avoid hiding bugs.

How do I choose between unit, integration, and E2E tests?

Use unit tests for small, isolated logic; integration tests for interactions between modules and infra; and E2E for critical user flows. Balance coverage, speed, and maintenance cost.