Wjttc Tester

---
name: wjttc-tester
description: Automated test suite generator and QA expert. Creates test plans, writes test files, finds bugs, and generates detailed reports. Use when testing any project, building regression suites, or running QA audits. Supports any language and framework.
license: Complete terms in LICENSE.txt
---

# WJTTC Championship Tester

## Philosophy

**"We break things so others never have to know they were broken."**

Apply Formula 1 engineering standards to software testing. When brakes must work flawlessly at 200mph, so must our code work flawlessly in production.

## When to Use This Skill

Activate this skill when:
- Testing new features or code changes
- Finding and documenting bugs
- Validating edge cases and error handling
- Performing regression testing
- Creating WJTTC test reports
- Reviewing code for potential failures
- Stress testing performance
- Validating data integrity
- Testing integrations and APIs
- Documenting test results

## WJTTC Testing Tiers (F1-Inspired)

### Tier 1: BRAKE SYSTEMS 🚨 (Life-Critical)
**When failure = catastrophic consequences**

**Examples:**
- File corruption or data loss
- Security vulnerabilities
- Authentication/authorization bypass
- Payment processing errors
- Data deletion without confirmation
- Backup/restore failures

**Testing Approach:**
- Zero tolerance for failures
- Test ALL edge cases
- Simulate worst-case scenarios
- Validate rollback mechanisms
- Document every failure mode

### Tier 2: ENGINE SYSTEMS ⚡ (Performance-Critical)
**When failure = poor experience or incorrect results**

**Examples:**
- API response accuracy
- Data transformation correctness
- Formula calculations
- File format compliance
- Cross-platform compatibility
- Performance benchmarks

**Testing Approach:**
- Validate core functionality
- Test with real-world data
- Measure performance metrics
- Check error handling
- Verify expected outputs

### Tier 3: AERODYNAMICS 🏁 (Polish & Edge Cases)
**When failure = minor inconvenience**

**Examples:**
- UI/UX edge cases
- Rare error message formatting
- Optional feature quirks
- Documentation accuracy
- Non-critical warnings

**Testing Approach:**
- Test common edge cases
- Validate user experience
- Check for graceful degradation
- Document known limitations

## Test Execution Process

### Step 0: Signal Integrity Pre-Audit (Run BEFORE adding any new tests)

**Doctrine: Red CI is a contract — it must always mean "stop, look, fix." If the existing reds don't, fix the signal before adding more tests.**

Before validating coverage or running new tests, audit the suite's existing signal trust. A test suite with high coverage but flaky reds is **less trustworthy** than a smaller suite with zero false alarms — because the team has stopped reading the reds.

**Audit method:** classify the last 30 days of CI failures into three buckets:

| Bucket | Definition | Verdict |
|--------|-----------|---------|
| **Real bug** | Red corresponded to an actual code defect; fixed by a code change | ✓ Signal worked |
| **Flake** | Red was timing/network/concurrency noise; passed on rerun, no code change | ✗ Test design defect |
| **Infra** | Red was missing secret, runner image change, dep upstream — not the code | ✗ Workflow design defect |

**Signal Integrity Score:**

```
SI = (Real bugs) / (Real bugs + Flakes + Infra) × 100
```

| SI % | Verdict | Required Action |
|------|---------|-----------------|
| 100% | TROPHY 🏆 | Maintain — exemplary signal |
| 95-99% | Championship | Annotate any flake immediately |
| 85-94% | Acceptable | Schedule flake-class fix this sprint |
| 70-84% | Eroding | Stop adding tests; fix flakes first |
| <70% | DEAD SIGNAL | Block all merges until signal restored |

**Common flake sources to eliminate on sight:**
- Hard absolute-time perf assertions on shared CI runners (`expect(time).toBeLessThan(30)`) — move to non-gating workflow
- Network-dependent tests in main suite — mock at the boundary
- Concurrency tests without explicit ordering
- Secret-dependent steps that fail when missing — grey-skip instead

**The inverse rule:** Green CI that passes when something is broken is equally a contract violation. If a real bug shipped despite green CI, write the regression test BEFORE the fix lands.

**The conversation is the real gate.** Automated CI is supporting infrastructure that serves the human + AI audit. Flaky CI wastes the audit's bandwidth. Signal Integrity exists to keep CI worthy of the conversation.

### Step 1: Understand What to Test

**Questions to Answer:**
- What is the feature/code supposed to do?
- What are the happy path scenarios?
- What are the edge cases?
- What could go wrong?
- What data formats are expected?
- What are the performance requirements?

### Step 2: Create Test Plan

**Define:**
- Test objectives
- Test scope (what's in/out)
- Test tier (Brake/Engine/Aero)
- Test scenarios (happy + edge + error)
- Expected results
- Pass/fail criteria

### Step 3: Execute Tests

**For Each Test:**
1. Set up test environment
2. Prepare test data
3. Execute test steps
4. Observe actual results
5. Compare to expected results
6. Document outcome (pass/fail/blocked)
7. Capture errors/screenshots if failed

### Step 4: Document Results

**Create WJTTC Report** (see format below)

## Test Scenario Types

### 1. Happy Path Testing
**Test the ideal, expected flow**

```yaml
Scenario: User creates new .faf file
Given: Valid project directory with package.json
When: User runs `faf init`
Then:
  - .faf file is created
  - File contains valid YAML
  - Project metadata is detected
  - Success message is displayed
```

### 2. Edge Case Testing
**Test boundary conditions and unusual inputs**

**Examples:**
- Empty strings
- Very long strings (>1000 chars)
- Special characters (unicode, emoji, etc.)
- Null/undefined values
- Empty arrays/objects
- Maximum/minimum numeric values
- Zero/negative numbers
- Duplicate data
- Concurrent operations

### 3. Error Handling Testing
**Test that errors are handled gracefully**

**Examples:**
- File doesn't exist
- Permission denied
- Network timeout
- Invalid input format
- Missing required fields
- Malformed JSON/YAML
- Circular references
- Out of memory
- Disk full

### 4. Integration Testing
**Test interactions between components**

**Examples:**
- API calls with different responses
- Database connections
- File system operations
- External service dependencies
- Authentication flows
- Data synchronization

### 5. Performance Testing
**Test speed, memory, and scalability**

**Metrics to Test:**
- Execution time (<50ms target for FAF operations)
- Memory usage
- File size handling (small, medium, large)
- Concurrent operations
- Load handling (100, 1000, 10000 items)

### 6. Regression Testing
**Test that old functionality still works**

**After:**
- Code refactoring
- Dependency updates
- New feature additions
- Bug fixes

## WJTTC Report Format

### Standard Report Template

```yaml
---
# WJTTC Test Report
project: "project-name"
feature: "feature-being-tested"
tester: "wolfejam (via Claude)"
date: "2025-10-20"
tier: "Tier 2 - Engine Systems"
---

## Test Summary

**Objective:** [What was being tested]
**Result:** [PASS / FAIL / BLOCKED]
**Duration:** [Time taken to run tests]
**Environment:** [OS, Node version, dependencies, etc.]

## Test Statistics

- **Total Tests:** 25
- **Passed:** 23
- **Failed:** 2
- **Blocked:** 0
- **Pass Rate:** 92%

## Test Scenarios

### 1. [Scenario Name]

**Tier:** Tier 1 - Brake Systems 🚨
**Status:** ✅ PASS
**Duration:** 15ms

**Test Steps:**
1. [Step 1]
2. [Step 2]
3. [Step 3]

**Expected Result:**
[What should happen]

**Actual Result:**
[What actually happened]

**Evidence:**
```
[Code output, logs, screenshots]
```

---

### 2. [Scenario Name]

**Tier:** Tier 2 - Engine Systems ⚡
**Status:** ❌ FAIL
**Duration:** 250ms

**Test Steps:**
1. [Step 1]
2. [Step 2]

**Expected Result:**
[What should happen]

**Actual Result:**
[What actually happened - THE FAILURE]

**Error Details:**
```
Error: [Actual error message]
Stack trace: [If applicable]
```

**Root Cause:**
[Analysis of why it failed]

**Recommended Fix:**
[How to fix the issue]

---

## Edge Cases Tested

| Case | Input | Expected | Actual | Status |
|------|-------|----------|--------|--------|
| Empty string | `""` | Error message | Error message | ✅ PASS |
| Null value | `null` | Error message | Error message | ✅ PASS |
| Very long string | `"a".repeat(10000)` | Handle gracefully | Crash | ❌ FAIL |
| Unicode emoji | `"🏎️"` | Store correctly | Stored correctly | ✅ PASS |

## Performance Metrics

| Operation | Target | Actual | Status |
|-----------|--------|--------|--------|
| File read | <50ms | 18ms | ✅ PASS |
| File write | <50ms | 23ms | ✅ PASS |
| Parse YAML | <50ms | 12ms | ✅ PASS |
| Score calculation | <50ms | 8ms | ✅ PASS |

## Bugs Found

### Bug #1: [Title]
**Severity:** High (Tier 1)
**Reproducibility:** Always
**Steps to Reproduce:**
1. [Step 1]
2. [Step 2]
3. [Step 3]

**Expected:** [What should happen]
**Actual:** [What happens instead]
**Impact:** [Who is affected, how serious]
**Suggested Fix:** [How to fix it]

---

## Test Coverage

**Tested:**
- ✅ Happy path scenarios
- ✅ Edge cases (empty, null, special chars)
- ✅ Error handling
- ✅ Performance benchmarks
- ✅ Cross-platform compatibility

**Not Tested:**
- ⏸️ Concurrent file access
- ⏸️ Files >100MB
- ⏸️ Network failures (not applicable)

## Recommendations

1. **Fix Critical Issues:**
   - [Issue 1]
   - [Issue 2]

2. **Improve Error Messages:**
   - [Suggestion 1]
   - [Suggestion 2]

3. **Performance Optimization:**
   - [Suggestion 1]

4. **Additional Testing Needed:**
   - [What else to test]

## Championship Certification

**Current Status:** ◆ Silver (92% pass rate)

**To Reach Championship 🏆:**
- Fix 2 failing tests
- Add tests for concurrent operations
- Validate with 10,000+ item datasets

---

## Appendix

**Test Data Used:**
```yaml
# Sample test data
test_cases:
  - name: "valid-project"
    input: {...}
  - name: "empty-project"
    input: {...}
```

**Environment Details:**
- OS: macOS 14.5
- Node: v18.17.0
- Dependencies: [list]

**Test Execution Logs:**
```
[Full test output if needed]
```

---

*Tested with Championship Standards 🏎️*
*WJTTC Certified - We break things so you don't have to*
```

## Testing Best Practices

### 1. Start with Tier 1 Tests
Always test life-critical functionality first. If brakes don't work, nothing else matters.

### 2. Test with Real Data
Don't just test with perfect, sanitized data. Use:
- Real user data (anonymized)
- Production-like datasets
- Messy, imperfect inputs

### 3. Automate What You Can
```javascript
// Example: Automated test script
const testCases = [
  { input: '', expected: 'error' },
  { input: 'valid', expected: 'success' },
  { input: null, expected: 'error' },
  { input: '🏎️', expected: 'success' }
];

testCases.forEach(test => {
  const result = functionToTest(test.input);
  console.log(`Input: ${test.input}, Expected: ${test.expected}, Actual: ${result}`);
});
```

### 4. Document Every Failure
Even small failures matter. Document:
- What failed
- How to reproduce
- Why it matters
- How to fix

### 5. Think Like an Attacker
**Ask:**
- What if someone tries to break this?
- What's the worst input I can give?
- What happens if I do things in the wrong order?
- Can I bypass validation?

### 6. Test the Unhappy Paths
Don't just test success scenarios:
```yaml
# Happy path
Input: Valid email
Result: Success

# Unhappy paths
Input: Invalid email → Error message
Input: Empty string → Error message
Input: null → Error message
Input: SQL injection attempt → Sanitized/rejected
Input: XSS attempt → Sanitized/rejected
```

### 7. Measure Everything
- Execution time
- Memory usage
- File sizes
- Error rates
- Pass/fail counts

## Common Test Patterns

### Pattern 1: Arrange-Act-Assert (AAA)

```javascript
// Arrange - Set up test data
const testData = { name: 'Test', value: 123 };

// Act - Execute the code being tested
const result = processData(testData);

// Assert - Verify the result
if (result.success === true && result.value === 123) {
  console.log('✅ PASS');
} else {
  console.log('❌ FAIL');
}
```

### Pattern 2: Test Table

```javascript
const testTable = [
  { input: 0, expected: 'zero' },
  { input: 1, expected: 'one' },
  { input: -1, expected: 'error' },
  { input: null, expected: 'error' }
];

testTable.forEach(({ input, expected }) => {
  const result = numberToWord(input);
  const status = result === expected ? '✅ PASS' : '❌ FAIL';
  console.log(`${status} - Input: ${input}, Expected: ${expected}, Got: ${result}`);
});
```

### Pattern 3: Boundary Value Testing

```javascript
// Test boundaries
const boundaries = [
  { value: -1, desc: 'Below minimum' },
  { value: 0, desc: 'Minimum' },
  { value: 1, desc: 'Just above minimum' },
  { value: 99, desc: 'Just below maximum' },
  { value: 100, desc: 'Maximum' },
  { value: 101, desc: 'Above maximum' }
];
```

## Integration with WJTTC

### Report Storage

**Save reports to:**
```
/Users/wolfejam/FAF-GOLD/PLANET-FAF/WJTTC - WolfeJam Technical & Testing Center/
├── reports/
│   ├── 2025-10-20-faf-cli-tests.yaml
│   ├── 2025-10-20-mcp-server-tests.yaml
│   └── 2025-10-20-n8n-workflow-tests.yaml
└── templates/
    └── WJTC-REPORT-FORMAT.yaml
```

### Report Naming Convention

```
YYYY-MM-DD-{project}-{feature}-tests.yaml
```

**Examples:**
- `2025-10-20-faf-cli-init-command-tests.yaml`
- `2025-10-20-claude-faf-mcp-bi-sync-tests.yaml`
- `2025-10-20-n8n-workflow-http-node-tests.yaml`

### Championship Scoring

**Pass Rate to Championship Tier:**
- 🏆 **95-100%** - Championship (Gold)
- ★ **85-94%** - Podium (Gold)
- ◆ **70-84%** - Points (Silver)
- ◇ **55-69%** - Midfield (Bronze)
- ● **40-54%** - Backmarker (Green)
- ● **25-39%** - Struggling (Yellow, dim)
- ○ **10-24%** - Critical (Red)
- ♡ **0-9%** - DNF (White)

## Quick Test Checklist

**Before releasing any code:**
- [ ] Happy path tested and passing
- [ ] Edge cases tested (empty, null, max, min)
- [ ] Error handling tested
- [ ] Performance meets targets (<50ms for FAF operations)
- [ ] Works on target platforms (macOS, Linux, Windows if applicable)
- [ ] Regression tests pass
- [ ] WJTTC report created and filed
- [ ] Critical bugs fixed (Tier 1)
- [ ] Pass rate ≥85% (Championship target)

## Example Test Execution

### Testing: faf-cli `init` command

```bash
# Test 1: Happy path
cd /tmp/test-project
faf init
# ✅ Expected: .faf file created
# ✅ Actual: .faf file created with valid YAML

# Test 2: Already exists
faf init
# ✅ Expected: Error message about existing file
# ✅ Actual: "Error: .faf file already exists"

# Test 3: No package.json
cd /tmp/empty-dir
faf init
# ✅ Expected: Still creates .faf, detects basic project info
# ✅ Actual: Created .faf with minimal structure

# Test 4: Permission denied
chmod 000 /tmp/readonly-dir
cd /tmp/readonly-dir
faf init
# ✅ Expected: Error message about permissions
# ✅ Actual: "Error: EACCES: permission denied"

# Test 5: Performance
time faf init
# ✅ Expected: <50ms
# ✅ Actual: 18ms (Championship grade!)
```

## Stress Testing

### Test with Extreme Data

```javascript
// Test with large arrays
const largeArray = Array(10000).fill(0).map((_, i) => ({ id: i }));

// Test with deeply nested objects
const deepNest = { level1: { level2: { level3: { level4: { level5: 'data' } } } } };

// Test with special characters
const specialChars = "!@#$%^&*(){}[]|\\:;\"'<>,.?/~`";

// Test with unicode
const unicode = "🏎️⚡️🏁🏆★◆◇●○♡";

// Test with very long strings
const longString = 'a'.repeat(100000);
```

---

## Skill Control

**To disable this skill temporarily:**
```bash
mv ~/.claude/skills/wjttc-tester ~/.claude/skills/wjttc-tester.disabled
```

**To re-enable:**
```bash
mv ~/.claude/skills/wjttc-tester.disabled ~/.claude/skills/wjttc-tester
```

---

*Made with 🧡 by wolfejam.dev*
*Championship Testing Standards 🏎️*
*"We break things so others never have to know they were broken."*