testing-anti-patterns_skill

Overview

This skill prevents common testing anti-patterns when writing or changing tests in TypeScript projects. It guides developers to avoid asserting on mocks, adding test-only methods to production classes, and mocking without understanding dependencies. The result is more reliable tests and cleaner production code.

How this skill works

The skill inspects test code and test-support code for red flags: assertions that target mock identifiers, production classes that expose methods used only by tests, and overly broad or incomplete mocks. It enforces a gate checklist before mocking or adding production APIs and recommends moving test-only logic into test utilities. It also suggests TDD steps and alternatives like lighter mocks or integration tests when mocks are too complex.

When to use it

• When adding or editing tests that introduce mocks or test IDs
• When tempted to add a method to a production class just for tests
• When a test relies on mocked behavior rather than real outcomes
• When mocks are large or test setup is longer than test assertions
• When test failures disappear after removing a mock

Best practices

• Ask whether you’re testing real behavior or mock existence before asserting on mock elements
• Keep test-only cleanup and helpers in test utilities, not in production classes
• Understand real method side effects before mocking; mock at the correct level
• Mirror real API responses and include all fields in mocks to avoid silent failures
• Favor TDD: write failing tests first to reveal true dependencies
• Prefer integration tests if mock setup becomes more complex than the behavior under test

Example use cases

• A component test asserting DOM created by a mock—replace assertion with a role-based check or unmock component
• A Session class with a destroy() used only in tests—move teardown into test-utils cleanup function
• A test that mocks a high-level method that performs side effects—mock the slow external operation instead
• A network client test failing due to missing metadata in a partial mock—create a mock matching the real response schema
• When mock setup is longer than the test, switch to an integration test with the real component