Skip to content

Latest commit

 

History

History
237 lines (181 loc) · 5.75 KB

QA_CHECKLIST.md

File metadata and controls

237 lines (181 loc) · 5.75 KB

QA Checklist - Test-Driven Ruchy Book

🧪 TDD Quality Assurance Protocol

Every change to this book MUST follow Test-Driven Development. No exceptions.

✅ Pre-Documentation Checklist (MANDATORY)

Before writing ANY documentation:

1. Test Creation

  • Test file created in tests/ch*/ directory
  • Test follows naming convention: test_XX_description.ruchy
  • Test uses fun main() structure
  • Test uses fun keyword (not fn)
  • Test is minimal and focused

2. Test Verification

  • ruchy compile test_file.ruchy succeeds
  • ./a.out produces expected output
  • make test-file FILE=test_file.ruchy passes
  • No compilation warnings or errors
  • Output matches documentation claims

3. Test Integration

  • Added to appropriate chapter test directory
  • Included in make test-chXX target
  • Passes make test (all tests)
  • Passes make lint (quality checks)
  • Listed in INTEGRATION.md

📝 Documentation Checklist

After tests pass, documentation must:

1. Accuracy

  • Every code example has corresponding test file
  • Test file path referenced in documentation
  • Output shown matches actual test output
  • Version compatibility stated (v1.1.0)
  • No untested features documented

2. Structure

  • Chapter marked as "Test-Driven"
  • Test count shown in header
  • "How to verify" section included
  • Test files referenced by path
  • Make commands documented

3. Quality

  • No TODO/FIXME/HACK comments
  • No "should work" statements
  • No "coming soon" promises
  • No placeholder content
  • No vaporware features

🔧 Technical Checklist

Code Standards

  • fun keyword used for Ruchy functions
  • fn only in Rust examples (clearly marked)
  • Consistent indentation (4 spaces)
  • No trailing whitespace
  • UTF-8 encoding

Testing Standards

  • Minimum 3 examples per chapter
  • Each example is self-contained
  • Examples build on each other logically
  • Edge cases tested where relevant
  • Error cases documented (if applicable)

Build Standards

  • make test passes (100% required)
  • make lint passes (no violations)
  • make validate passes (all checks)
  • make build succeeds (book builds)
  • No large files (>1MB) committed

📊 Metrics Requirements

Per Chapter

  • Test Coverage: 100% (all examples tested)
  • Pass Rate: 100% (no failures allowed)
  • Documentation: Complete (no gaps)
  • Quality: A+ (clean, tested, verified)

Overall Book

  • Foundation Chapters: ✅ 11/11 tests passing
  • Intermediate Chapters: ⏳ In development
  • Advanced Chapters: ⏳ Planned
  • Total Tests: 11+ (growing with each sprint)
  • Success Rate: 100% (mandatory)

🚀 Release Checklist

Before any release or major commit:

1. Test Suite

  • make test - All tests pass
  • make test-ch01 - Chapter 1 passes
  • make test-ch02 - Chapter 2 passes
  • make test-ch03 - Chapter 3 passes
  • make test-foundation - All foundation passes

2. Quality Gates

  • make lint - No issues found
  • make format - Formatting checked
  • make validate - All validations pass
  • No SATD comments in codebase
  • No broken examples

3. Documentation

  • INTEGRATION.md updated with status
  • README.md reflects current state
  • ROADMAP.md shows completed work
  • Version numbers consistent (v1.1.0)
  • Test counts accurate

4. Repository

  • No binary files (a.out, etc.)
  • No temporary files
  • No debug artifacts
  • .gitignore updated if needed
  • Commit message follows format

🛑 Blocking Issues

These issues MUST be fixed before proceeding:

Critical Blockers

  • ❌ Any test failure
  • ❌ Documented feature doesn't work
  • ❌ Version mismatch
  • ❌ Missing test files
  • ❌ Untested documentation

Quality Blockers

  • ❌ SATD comments present
  • ❌ Vaporware documentation
  • ❌ Placeholder content
  • ❌ Function keyword misuse
  • ❌ Large file commits

📋 Sprint Completion Checklist

At the end of each sprint:

1. Tests

  • All sprint tests written
  • 100% pass rate achieved
  • Tests organized by chapter
  • Test counts documented
  • Performance acceptable

2. Documentation

  • Chapters written from tests
  • Examples reference test files
  • Verification instructions included
  • No untested features
  • Version compatibility noted

3. Integration

  • INTEGRATION.md updated
  • Sprint marked complete
  • Metrics documented
  • Next sprint planned
  • Commit pushed to main

🔄 Continuous Improvement

Weekly Review

  • Review test failures (should be zero)
  • Update test coverage metrics
  • Plan next week's tests
  • Review community feedback
  • Update roadmap if needed

Monthly Review

  • Sprint retrospective
  • Quality metrics analysis
  • Process improvements
  • Tool updates
  • Documentation review

📞 Escalation Path

If quality gates fail:

  1. Stop all work - Don't continue with failures
  2. Fix immediately - Tests must pass first
  3. Document issue - Update INTEGRATION.md
  4. Review process - Why did it fail?
  5. Prevent recurrence - Update this checklist

✨ Success Criteria

A successful Ruchy book contribution:

  1. ✅ Tests written before documentation
  2. ✅ 100% of tests passing
  3. ✅ Documentation matches tests exactly
  4. ✅ Quality gates all green
  5. ✅ INTEGRATION.md updated
  6. ✅ Version compatibility verified
  7. ✅ No untested features
  8. ✅ Community can verify examples
  9. ✅ Follows Toyota Way principles
  10. ✅ Improves reader confidence

Remember: Test first, document what works, never promise what doesn't exist.

Last Updated: 2025-08-23 Book Version: 2.0.0-TDD Compliance: 100% TDD