--- frontmattername: Testing Patterns
description: This skill should be used when the user asks to "write tests", "test strategy", "coverage", "unit test", "integration test", or needs testing guidance. Provides testing methodology and patterns.
<test_phase>Act: Execute the code under test</test_phase>
total = cart.calculate_total
<test_phase>Assert: Verify expected outcomes</test_phase>
assert_equal 0, total
<bdd_step>When: Action or trigger</bdd_step>
when_the_user_calculates_total
<bdd_step>Then: Expected outcome</bdd_step>
then_the_total_should_be_zero
def save(key, value)
@data[key] = value
end
def find(key)
@data[key]
end
end
<best_practices>
<practice priority="critical">
<name>Test happy path first</name>
<description>Start with the normal, expected flow before edge cases</description>
<example>
test_userLogin_withValidCredentials_succeeds
test_userLogin_withInvalidPassword_fails
test_userLogin_withLockedAccount_fails
</example>
</practice>
<practice priority="critical">
<name>Test edge cases</name>
<description>Test boundary conditions and limits</description>
<example>
Empty inputs, maximum values, null values, zero values, negative numbers
</example>
</practice>
<practice priority="critical">
<name>Test error cases</name>
<description>Verify error handling paths work correctly</description>
<example>
Invalid inputs, network failures, permission errors, timeout scenarios
</example>
</practice>
<practice priority="high">
<name>Isolate tests</name>
<description>Each test should be independent</description>
<example>
<note>Use setup/teardown to reset state</note>
def setup
@database = TestDatabase.new
@service = UserService.new(@database)
end
def teardown
@database.clear
end
</example>
<note>Bad: Unclear purpose</note>
test_user_reg_1
</example>
<note>Avoid: Multiple unrelated assertions</note>
test_userCreation
user = create_user
assert_equal "member", user.role
assert_not_nil user.email
assert_true user.active
end
</example>
<bad_example>Bad</bad_example>
test_userValidation_withValidAge_succeeds
user = User.new(age: 25)
assert user.valid?
end
</example>
<related_skills>
<skill name="requirements-definition">Use to define test requirements and acceptance criteria</skill>
<skill name="execution-workflow">Use to implement tests as part of feature development workflow</skill>
<skill name="investigation-patterns">Use when debugging test failures or flaky tests</skill>
</related_skills>
<anti_patterns>
<avoid name="testing_implementation">
<description>Testing implementation details instead of behavior</description>
<instead>Focus on testing observable behavior and outcomes, not internal implementation details. Test what the code does, not how it does it.</instead>
</avoid>
<avoid name="excessive_mocking">
<description>Over-mocking dependencies throughout test suites</description>
<instead>Use real implementations where practical; excessive mocking often indicates poor design. Only mock external dependencies or slow operations.</instead>
</avoid>
<avoid name="flaky_tests">
<description>Tests that sometimes pass and sometimes fail</description>
<instead>Ensure tests are deterministic by controlling time, randomness, and async operations. Use fixed timestamps, seeded random generators, and proper async handling.</instead>
</avoid>
<avoid name="slow_tests">
<description>Tests that take too long to run</description>
<instead>Use unit tests for fast feedback; reserve slow integration/e2e tests for critical paths. Unit tests should run in milliseconds, not seconds.</instead>
</avoid>
<avoid name="test_interdependence">
<description>Tests that depend on execution order or shared state</description>
<instead>Make each test independent with proper setup/teardown and isolated state. Each test should create its own test data.</instead>
</avoid>
</anti_patterns>
<error_escalation>
<level severity="low">
<example>Minor coverage gap in non-critical path</example>
<action>Note in report, proceed</action>
</level>
<level severity="medium">
<example>Test flakiness detected</example>
<action>Document issue, use AskUserQuestion for clarification</action>
</level>
<level severity="high">
<example>Critical path lacks test coverage</example>
<action>STOP, present options to user</action>
</level>
<level severity="critical">
<example>Tests reveal security vulnerability</example>
<action>BLOCK operation, require explicit user acknowledgment</action>
</level>
</error_escalation>
<constraints>
<must>Follow project test patterns</must>
<must>Run tests after creation</must>
<must>Cover critical paths first</must>
<avoid>Creating tests without understanding implementation</avoid>
<avoid>Writing flaky or non-deterministic tests</avoid>
<avoid>Ignoring existing test conventions</avoid>
</constraints>