Nw Test Refactoring CatalogSAFE
AI agents that guide you from idea to working code, with you in control at every step.
Overview
AI agents that guide you from idea to working code, with you in control at every step.
1a864ec81cdeOBSERVED · 2026-10-14What it tells the agent
The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.
---
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
```python
# 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.Trust audit
SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | PASS |
| L1 | Static analysis of the code | NA |
| L2 | Instruction surface (what it tells the agent) | PASS |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
What the source does
- Filesystem
- none-observed
- Network
- none-observed
- Shell
- none-observed
- Dependencies
- pinned
- Secrets in source
- none-found
Findings (0)
No findings outside the package's declared scope.
Gates applied: no_behavioural_pass.
1a864ec81cdefull audit observations/trust-audit/skill/nwave-ai__nw-test-refactoring-catalog.json · Report an issue / request a re-scanAudit history
Every audit this skill has had.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-10-14 | 1a864ec81cde | SAFE | B | 89 | first audit |
Questions
What does the Nw Test Refactoring Catalog skill do?
AI agents that guide you from idea to working code, with you in control at every step.
Is Nw Test Refactoring Catalog safe to install?
The audit found nothing in the source that contradicts what it says it does, and graded it B (89/100). Grade A is held back for packages that have also passed a sandboxed behavioural run, which is why a clean skill reads B.
What can Nw Test Refactoring Catalog access on my machine?
The audit observed no filesystem, network or shell use at all in its source.
How current is this page?
The grade is for one exact copy of the source (1a864ec81cde), read on 2026-10-14. The repository is watched, and a new audit runs when it changes — this is the first audit.