/nw-test-refactoring-catalog
Detailed refactoring mechanics with step-by-step procedures, and test code smell catalog with detection patterns and before/after examples
$ npx -y skills add nWave-ai/nWave --skill nw-test-refactoring-catalog --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/nw-test-refactoring-catalog
Context preview
The summary Claude sees to decide when to auto-load this skill.
Detailed refactoring mechanics with step-by-step procedures, and test code smell catalog with detection patterns and before/after examples
SKILL.md
nw-test-refactoring-catalog.SKILL.mdname: nw-test-refactoring-catalog
description: Detailed refactoring mechanics with step-by-step procedures, and test code smell catalog with detection patterns and before/after examples
user-invocable: false
disable-model-invocation: true
Test Refactoring Catalog
Test Code Smells (Full Detail)
L1 Readability Smells
Obscure Test
- **Problem**: test name does not reveal business scenario being tested
- **Detection**: generic names like Test1(), ProcessOrderTest(), or names requiring reading test body to understand
- **Solution**: rename to Given_When_Then or should_do_expected_thing_when_condition format
Before: public void Test1() { /* ... */ }
After: public void ProcessOrder_PremiumCustomer_AppliesCorrectDiscount() { /* ... */ }Hard-Coded Test Data
- **Problem**: magic numbers and strings obscure business rules being tested
- **Detection**: numbers like 1000, 0.15, strings without explanation
- **Solution**: extract to named constants that reveal business meaning
Before: Assert.Equal(850, result.Total); // What discount?
After: const decimal EXPECTED_TOTAL = 1000 * (1 - 0.15m);
Assert.Equal(EXPECTED_TOTAL, result.Total);Assertion Roulette
- **Problem**: multiple assertions without messages make failures unclear
- **Detection**: multiple Assert.* calls without message parameter
- **Solution**: add descriptive message to each assertion explaining expected business outcome
L2 Complexity Smells
Eager Test
- **Problem**: single test verifies multiple unrelated behaviors
- **Detection**: multiple arrange/act/assert cycles or assertions testing different concerns
- **Solution**: split into focused tests, one per business scenario
Before: ProcessOrderTest() { /* tests discount AND shipping AND tax */ }
After: ProcessOrder_AppliesDiscount()
ProcessOrder_CalculatesShipping()
ProcessOrder_CalculatesTax()Prefer parameterized tests for variations of the same behavior.
Test Code Duplication
- **Problem**: repeated test setup logic across multiple tests
- **Detection**: same object creation, mock setup, or data builders copied in 3+ tests
- **Solution**: extract helper methods
Extract: CreatePremiumCustomer(), CreateHighValueOrder()
Conditional Test Logic
- **Problem**: if/switch statements in test code make tests non-deterministic
- **Detection**: if, switch, for loops in test methods
- **Solution**: replace with parameterized tests
# Before: if/else in test
# After:
@pytest.mark.parametrize("input,expected", [...])
def test_behavior(input, expected): ...L3 Organization Smells
Mystery Guest
- **Problem**: test depends on external files or hidden dependencies
- **Detection**: File.ReadAllText, database queries, external config in tests
- **Solution**: inline test data or make dependency explicit in test setup
Test Class Bloat
- **Problem**: single test class contains tests for multiple unrelated concerns
- **Detection**: test class with 15+ tests covering different features
- **Solution**: split by feature
Before: UserServiceTests (31 tests)
After: UserAuthTests, UserProfileTests, UserNotificationTests
General Fixture
- **Problem**: shared fixture used by tests with different needs
- **Detection**: SetUp method creates data used by only some tests
- **Solution**: move to per-test setup methods or test-specific fixtures
For production code refactoring techniques and mechanics, load the progressive-refactoring skill.
Read more
name: nw-test-refactoring-catalog description: Detailed refactoring mechanics with step-by-step procedures, and test code smell catalog with detection patterns and before/after examples user-invocable: false disable-model-invocation: true
Test Refactoring Catalog
Test Code Smells (Full Detail)
L1 Readability Smells
Obscure Test
- **Problem**: test name does not reveal business scenario being tested
- **Detection**: generic names like Test1(), ProcessOrderTest(), or names requiring reading test body to understand
- **Solution**: rename to Given_When_Then or should_do_expected_thing_when_condition format
Before: public void Test1() { /* ... */ }
After: public void ProcessOrder_PremiumCustomer_AppliesCorrectDiscount() { /* ... */ }Hard-Coded Test Data
- **Problem**: magic numbers and strings obscure business rules being tested
- **Detection**: numbers like 1000, 0.15, strings without explanation
- **Solution**: extract to named constants that reveal business meaning
Before: Assert.Equal(850, result.Total); // What discount?
After: const decimal EXPECTED_TOTAL = 1000 * (1 - 0.15m);
Assert.Equal(EXPECTED_TOTAL, result.Total);Assertion Roulette
- **Problem**: multiple assertions without messages make failures unclear
- **Detection**: multiple Assert.* calls without message parameter
- **Solution**: add descriptive message to each assertion explaining expected business outcome
L2 Complexity Smells
Eager Test
- **Problem**: single test verifies multiple unrelated behaviors
- **Detection**: multiple arrange/act/assert cycles or assertions testing different concerns
- **Solution**: split into focused tests, one per business scenario
Before: ProcessOrderTest() { /* tests discount AND shipping AND tax */ }
After: ProcessOrder_AppliesDiscount()
ProcessOrder_CalculatesShipping()
ProcessOrder_CalculatesTax()Prefer parameterized tests for variations of the same behavior.
Test Code Duplication
- **Problem**: repeated test setup logic across multiple tests
- **Detection**: same object creation, mock setup, or data builders copied in 3+ tests
- **Solution**: extract helper methods
Extract: CreatePremiumCustomer(), CreateHighValueOrder()
Conditional Test Logic
- **Problem**: if/switch statements in test code make tests non-deterministic
- **Detection**: if, switch, for loops in test methods
- **Solution**: replace with parameterized tests
# Before: if/else in test
# After:
@pytest.mark.parametrize("input,expected", [...])
def test_behavior(input, expected): ...L3 Organization Smells
Mystery Guest
- **Problem**: test depends on external files or hidden dependencies
- **Detection**: File.ReadAllText, database queries, external config in tests
- **Solution**: inline test data or make dependency explicit in test setup
Test Class Bloat
- **Problem**: single test class contains tests for multiple unrelated concerns
- **Detection**: test class with 15+ tests covering different features
- **Solution**: split by feature
Before: UserServiceTests (31 tests) After: UserAuthTests, UserProfileTests, UserNotificationTests
General Fixture
- **Problem**: shared fixture used by tests with different needs
- **Detection**: SetUp method creates data used by only some tests
- **Solution**: move to per-test setup methods or test-specific fixtures
For production code refactoring techniques and mechanics, load the progressive-refactoring skill.
AI agents that guide you from idea to working code, with human judgment at every gate. nWave runs inside Claude Code. It breaks feature delivery into seven waves (discover, diverge, discuss, design, devops, distill, deliver).
Repo: nWave-ai/nWave
Other skills on nwave.
- /nw-ab-critique-dimensions
Review dimensions for validating agent quality - template compliance, safety, testing, and priority validation
Open skill - /nw-abr-critique-dimensions
Review dimensions for validating agent quality - template compliance, safety, testing, and priority validation
Open skill - /nw-ad-critique-dimensions
Review dimensions for acceptance test quality - happy path bias, GWT compliance, business language purity, coverage completeness, walking skeleton user-centricity, priority validation, observable behavior assertions, traceability coverage, and walking skeleton boundary proof
Open skill - /nw-agent-creation-workflow
Detailed 5-phase workflow for creating agents - from requirements analysis through validation and iterative refinement
Open skill - /nw-agent-testing
5-layer testing approach for agent validation including adversarial testing, security validation, and prompt injection resistance
Open skill - /nw-architectural-styles-tradeoffs
Architectural style selection decision matrices, trade-off analysis, structural enforcement rules, and combination patterns. Load when choosing or evaluating architecture styles.
Open skill

