mirror of
https://github.com/MLSysBook/TinyTorch.git
synced 2026-04-29 10:57:59 -05:00
🔄 CONSOLIDATION: Merged separate testing patterns into module development best practices �� COMPREHENSIVE GUIDE NOW INCLUDES: - Complete testing architecture (inline → module → integration → system) - pytest requirements for all testing levels (ALWAYS use pytest) - Real data requirements for integration/system tests - Stubbed dependencies for module-level isolation - Detailed examples for each testing tier - Anti-patterns covering testing mistakes - Quality standards including testing requirements - Complete development workflow with testing integration 🧪 TESTING ARCHITECTURE CLARIFIED: - Inline unit tests: Immediate feedback in development code - Module tests: pytest with stubbed dependencies (isolation) - Integration tests: pytest with real modules and real data - System tests: pytest with complete workflows and real datasets 📚 EDUCATIONAL BENEFITS: - Students learn proper testing architecture - Immediate feedback through inline tests - Professional pytest usage throughout - Real-world testing patterns and practices - Clear separation of concerns across testing levels This creates one comprehensive reference document for both module development and testing practices, eliminating duplication and ensuring consistency.
1.0 KiB
1.0 KiB
Development Workflow Rules
Branch-First Development
- Always create a branch for any work - never work directly on main
- Branch naming:
feature/description,fix/issue,refactor/component - Remind user to create branches if they forget
Work Process
- Plan: Define what changes are needed and why
- Reason: Think through the approach and potential issues
- Test: Write tests to verify success before implementing
- Execute: Implement changes in a new Git branch
- Verify: Run all tests and ensure everything works
- Merge: Only merge when fully tested and verified
Testing Standards
- Always use pytest for all tests
- Test before implementing - write tests that define success
- Test after implementing - verify everything works
- Test edge cases and error conditions
Documentation
- Prefer Quarto for documentation generation
- Keep rules short and actionable
- Update rules as patterns emerge
This ensures quality, traceability, and prevents breaking main branch.