| Age | Commit message (Collapse) | Author |
|---|
|
Introduce new section in 'quality-engineer.org' detailing how to
refactor code to enhance testability. Emphasizes recognizing deep
nesting, long functions, and overmocking as refactoring signals.
Provides strategies such as extracting functions and clear
separation of concerns. Offers real-world examples and guidelines on
effective mocking to maintain tests that are resilient to
implementation changes. Enhanced content in 'coder.org' with deeper
insights into handling deep nesting scenarios.
|
|
Document key lessons from chime.el timestamp refactoring project:
## New Sections Added
**Test Future-Proofing & Time-Based Testing**
- Dynamic timestamp generation patterns and benefits
- Never hardcode dates in tests - use relative time helpers
- Mock time via function substitution (with-test-time pattern)
- Code examples showing before/after patterns
**Large-Scale Test Refactoring Strategy**
- Strategic planning: tackle biggest challenges first
- Execution approach: maintain 100% pass rate throughout
- Project management: track progress visibly, celebrate milestones
- Know when you're done: not all files need changes
**Real-World Example**
- chime.el project: 23 files, 339 tests
- 16 files refactored (251 tests), 7 files skipped (88 tests)
- 100% pass rate maintained across all refactoring
- Result: future-proof test suite that never expires
## Key Insights
- "Tackle biggest challenge first" eliminates intimidation
- Work in batches but commit individually for clean history
- Don't let perfectionism create unnecessary work
- Strategic approach builds momentum and confidence
Added "Hardcoded dates in tests" to Red Flags section.
These lessons capture the methodology that successfully completed
the hardest refactoring task in the project.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
|
|
Added detailed guidelines and examples for writing effective
integration tests in the quality-engineer documentation. This
includes naming conventions, docstring requirements, file structure,
and when to use integration tests. Expanded sections cover balancing
test types and organizing test files for clarity and
maintainability.
|
|
Expand file organization to include unit and integration test
directions. Provide detailed naming conventions with examples.
Clarify expected result naming to ensure tests are self-documenting.
|
|
|
|
|
|
|
|
|
|
|
|
|
