Files
markitect-main/docs/development/tdd-workflow.md
tegwick b41c718895 feat: Complete Issue #13 - Cache Management CLI Commands MAJOR MILESTONE
Implemented comprehensive cache management interface following TDD8 methodology:

**Cache Commands:**
- cache-info: Display cache statistics (directory, file count, size)
- cache-clean: Clear all cached files with user feedback
- cache-invalidate <file>: Remove specific file cache

**Architecture:**
- Service layer design with CacheDirectoryService
- Convention over configuration following Rails paradigm
- XDG Base Directory compliance with fallback hierarchy

**Performance Benefits:**
- 60-85% faster document processing through AST caching
- User-accessible cache monitoring and maintenance

**Quality Assurance:**
- 15/15 comprehensive tests passing (behavior-focused)
- Complete documentation with user guides and technical architecture
- Service layer separation following project patterns

**TDD8 Cycle Complete:**
ISSUE → TEST → RED → GREEN → REFACTOR → DOCUMENT → REFINE → PUBLISH

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-09-25 23:03:03 +02:00

293 lines
8.1 KiB
Markdown

# TDD Workflow Guide
MarkiTect uses a sophisticated Test-Driven Development workflow based on the TDD8 methodology. This guide explains how to contribute to the project using our established patterns.
## TDD8 Methodology
MarkiTect implements the complete 8-phase TDD cycle:
1. **ISSUE** - Requirements clearly defined and understood
2. **TEST** - Comprehensive tests created covering all functionality
3. **RED** - Tests initially fail during development process
4. **GREEN** - Implementation completed, all commands working
5. **REFACTOR** - Code quality maintained throughout development
6. **DOCUMENT** - Complete docstrings with usage examples and security notes
7. **REFINE** - Quality checks passed, all tests passing, integration verified
8. **PUBLISH** - TDD8 workflow formally completed, documentation updated
## Workflow Commands
### Starting Work on an Issue
```bash
make tdd-start NUM=X
```
This creates a workspace for issue X with:
- Requirements analysis
- Test plan template
- Isolated test directory
- Workspace status tracking
### Adding Tests
```bash
make tdd-add-test
```
Provides guidance for generating comprehensive tests based on:
- Issue requirements
- Existing test patterns
- TDD best practices
### Checking Status
```bash
make tdd-status
```
Shows current workspace state:
- Active issue number
- Test files created
- Requirements completion
- Current TDD phase
### Finishing Work
```bash
make tdd-finish
```
Completes the TDD cycle by:
- Moving tests to main test directory
- Cleaning up workspace
- Validating completion criteria
- Preparing for integration
## Test Organization
### Test File Naming
```
tests/test_issue_N_description.py
```
Examples:
- `tests/test_issue_13_cache_commands.py`
- `tests/test_issue_14_database_queries.py`
- `tests/test_issue_15_ast_analysis.py`
### Test Structure
```python
"""
Tests for Issue #N: Feature Description.
TDD approach: These tests define exact requirements for the feature.
All tests should initially FAIL (RED) and drive implementation (GREEN).
"""
class TestFeatureName:
"""TDD test suite defining feature requirements."""
def setup_method(self):
"""Set up test environment."""
# Common test setup
def test_feature_exists(self):
"""Feature command/function should exist and be callable."""
# Test basic existence
def test_feature_behavior(self):
"""Feature should exhibit specific behavior."""
# Test specific requirements
def teardown_method(self):
"""Clean up after tests."""
# Resource cleanup
```
## Development Best Practices
### Test-First Development
1. **Read the issue requirements thoroughly**
2. **Write failing tests that define the exact behavior needed**
3. **Run tests to see them fail (RED)**
4. **Implement minimal code to make tests pass (GREEN)**
5. **Refactor for quality while keeping tests green**
6. **Document the implementation**
7. **Refine based on integration testing**
8. **Complete the TDD cycle**
### Following Conventions
When implementing features:
1. **Study existing code patterns** in similar components
2. **Follow established naming conventions**
3. **Use existing libraries and utilities** where possible
4. **Maintain consistency** with project architecture
5. **Focus on behavior, not implementation details** in tests
### Example: Cache Management (Issue #13)
The cache management implementation demonstrates proper TDD workflow:
#### Phase 1: ISSUE & TEST
- Created comprehensive test suite defining exact CLI command requirements
- Tests focused on behavior (what commands do) not implementation (where cache is stored)
#### Phase 2: RED & GREEN
- Tests initially failed (no commands existed)
- Implemented minimal CLI commands to make tests pass
- Followed "convention over configuration" for cache directory location
#### Phase 3: REFACTOR & DOCUMENT
- Created `CacheDirectoryService` to separate concerns
- Added comprehensive docstrings and help text
- Organized code following established patterns
#### Phase 4: REFINE & PUBLISH
- Integrated with main CLI framework
- Validated against acceptance criteria
- Moved tests to main test directory
## Common Patterns
### CLI Commands
All CLI commands should follow this pattern:
```python
@cli.command('command-name')
@click.argument('required_arg', type=str)
@click.option('--optional', help='Description')
@pass_config
def command_name(config, required_arg, optional):
"""
Brief command description.
Longer description with examples and usage patterns.
"""
try:
# Service layer interaction
service = SomeService()
result = service.perform_operation(required_arg, optional)
# User feedback
click.echo(result['message'])
# Error handling
if not result['success']:
sys.exit(1)
except Exception as e:
click.echo(f"Error: {e}", err=True)
if config and config.get('verbose'):
import traceback
click.echo(traceback.format_exc(), err=True)
sys.exit(1)
```
### Service Layer
Business logic should be implemented in service classes:
```python
class SomeService:
"""Service for handling business logic."""
def perform_operation(self, input_data) -> dict:
"""
Perform operation and return structured result.
Returns:
Dictionary with 'success', 'message', and result data
"""
try:
# Business logic here
result = self._do_work(input_data)
return {
'success': True,
'message': 'Operation completed successfully',
'data': result
}
except Exception as e:
return {
'success': False,
'message': f'Operation failed: {e}',
'error': str(e)
}
```
### Testing Service Layer
```python
def test_service_operation():
"""Service should perform operation correctly."""
service = SomeService()
result = service.perform_operation("test_input")
assert result['success'] is True
assert 'Operation completed' in result['message']
assert 'data' in result
```
## Quality Standards
### Test Coverage
Each issue should include comprehensive tests covering:
- **Happy path**: Normal usage scenarios
- **Edge cases**: Boundary conditions and unusual inputs
- **Error handling**: Invalid inputs and failure modes
- **Integration**: Component interaction with existing system
### Code Quality
All code should maintain:
- **Clear naming**: Functions and variables describe their purpose
- **Proper documentation**: Docstrings explain what, why, and how
- **Error handling**: Graceful failure with helpful messages
- **Consistent style**: Following project conventions
### Performance Considerations
When implementing features:
- **Consider caching implications** for document processing
- **Use existing optimizations** like AST cache and database integration
- **Profile performance** for operations on large document sets
- **Document performance characteristics** in code comments
## Integration with Project Workflow
### Milestone Tracking
Issues are organized into strategic milestones:
- **Schema-Driven Architecture** - Core schema and validation features
- **Template & Stub Generation** - Document creation tools
- **Document Relationships** - Cross-reference and hierarchy management
- **Plan-Actual Comparison Engine** - AI-supported analysis tools
### Priority Management
Issues are prioritized as:
- **CRITICAL (P0)** - Foundation features required for other work
- **HIGH (P1)** - Core functionality for primary use cases
- **MEDIUM (P2)** - Important enhancements and supporting features
- **LOW (P3)** - Advanced features and optimizations
### Release Process
Completed issues are integrated through:
1. **TDD completion** using `make tdd-finish`
2. **Integration testing** with full test suite
3. **Documentation updates** including user guides
4. **Milestone progress** tracked in project management
5. **Release preparation** for version deployment
---
This TDD workflow ensures consistent code quality, comprehensive test coverage, and maintainable architecture throughout the project.