
wjttc-tester
by Wolfe-Jam
Championship-Grade Claude Code Skills for project.faf Files
SKILL.md
name: wjttc-tester description: F1-inspired software testing expert. Tests any software with championship-grade standards and writes detailed WJTTC reports. Use when testing code, finding bugs, validating functionality, performing edge case analysis, or creating test reports. Follows F1 philosophy - when brakes must work flawlessly, so must our code. license: MIT
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 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:
- Set up test environment
- Prepare test data
- Execute test steps
- Observe actual results
- Compare to expected results
- Document outcome (pass/fail/blocked)
- 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
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
---
# 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:** 🥈 Bronze (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:
# 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)
// 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
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
// 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 project directory:
./wjttc-reports/
├── reports/
│ ├── 2025-10-20-feature-tests.yaml
│ └── 2025-10-20-regression-tests.yaml
└── templates/
└── WJTTC-REPORT-FORMAT.yaml
Report Naming Convention
YYYY-MM-DD-{project}-{feature}-tests.yaml
Examples:
2025-10-20-faf-cli-init-command-tests.yaml2025-10-20-claude-faf-mcp-bi-sync-tests.yaml2025-10-20-n8n-workflow-http-node-tests.yaml
Championship Scoring
Pass Rate to Championship Tier:
- 🏆 95-100% - Championship (Gold)
- 🥇 85-94% - Podium (Silver)
- 🥈 70-84% - Points (Bronze)
- 🥉 55-69% - Midfield
- 🟢 40-54% - Backmarker
- 🟡 25-39% - Struggling
- 🔴 10-24% - Critical
- 🤍 0-9% - DNF (Did Not Finish)
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
# 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
// 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:
mv ~/.claude/skills/wjttc-tester ~/.claude/skills/wjttc-tester.disabled
To re-enable:
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."
スコア
総合スコア
リポジトリの品質指標に基づく評価
SKILL.mdファイルが含まれている
ライセンスが設定されている
100文字以上の説明がある
GitHub Stars 100以上
3ヶ月以内に更新がある
10回以上フォークされている
オープンIssueが50未満
プログラミング言語が設定されている
1つ以上のタグが設定されている
レビュー
レビュー機能は近日公開予定です


