Developer Checklist
Comprehensive validation checklist for backend and frontend development in gnwebsite project.
When to Use This Skill
- Before committing any code changes
- When implementing new backend models, endpoints, or filters
- When integrating frontend components with APIs
- Before creating pull requests
- When troubleshooting test failures
- When you hear: "What should I check before committing?"
Test Execution - CRITICAL
Frontend Tests
ALWAYS use npm run test:run (NOT npm test):
# ✅ CORRECT - Tests run once and exit
npm run test:run
# ❌ WRONG - Tests hang in watch mode
npm test
npm run test
Backend Tests
# Run all tests
cd backend && python manage.py test
# Run specific test class
cd backend && python manage.py test jewelry_portfolio.api_test.JewelryAPIIntegrationTest
Backend Feature Implementation Checklist
New Model/Field
- Write tests for all query methods
- Test CRUD operations
- Test field validation and constraints
- Run:
python manage.py test✅
New Endpoint
- Write tests for GET, POST, PUT, DELETE as applicable
- Test authentication/permissions
- Test error responses (400, 401, 403, 404, 500)
- Verify API contract with OpenAPI schema
- Run:
python manage.py test✅
New Filter
- Test single value:
?filter=value - Test multiple values:
?filter1=value1&filter2=value2 - Test edge cases: empty, invalid, null values
- Test case sensitivity if applicable
- Use correct filter type:
BooleanFilterfor booleans (NOTCharFilter) - Run:
python manage.py test✅
Model Changes
- Update related serializers
- Update related tests
- Check for migration conflicts
- Regenerate OpenAPI schema:
python manage.py spectacular --file openapi_schema.json
Frontend Feature Implementation Checklist
API Integration
- Check if API tests exist for the endpoint
- If tests missing: Request backend tests FIRST
- Update service to match tested API contract exactly
- Use typed mock data from API tests
Component Updates
- Add tests for components using API data
- Verify TypeScript types match API contract
- Test error handling and loading states
- Test user interactions
- Run:
npm run test:run✅ - Run:
npm run type-check✅
After Backend API Changes
- Regenerate TypeScript client:
npx @openapitools/openapi-generator-cli generate - Update service layer types
- Update component types
- Update test mocks
Pre-Commit Checklist
Run BEFORE every commit:
- Backend tests pass:
cd backend && python manage.py test - Frontend tests pass:
cd frontend && npm run test:run - TypeScript types valid:
cd frontend && npm run type-check - No console errors in browser dev tools
- Code follows project style (check existing code)
Pre-Pull Request Checklist
Before creating ANY pull request:
- All tests pass locally (backend + frontend)
- Tested manually in browser
- Related documentation updated (CODEBASE_CHANGELOG.md)
- No console warnings/errors
- Changes don't break other features
- Commit messages are descriptive
Test Failure Troubleshooting
Backend Tests Failed
- Read the error message carefully
- Check if the test expectation is correct
- Fix the implementation to match test expectations
- NEVER delete tests to make them pass
Common backend issues:
- Wrong filter type (CharFilter vs BooleanFilter)
- Missing API test coverage
- Serializer/model mismatch
- Migration conflicts
Frontend Tests Failed
- Check if mock data matches actual API contract
- Verify component logic is correct
- Update test expectations if implementation is correct
- NEVER delete tests to make them pass
Common frontend issues:
- Outdated OpenAPI schema
- Mock data doesn't match API response structure
- Missing pagination handling
- Type mismatches (snake_case vs camelCase)
Common Mistakes to Avoid
❌ DON'T
# Commit without tests
git commit "Add category filter to frontend"
# Result: API breaks, frontend breaks
# Use wrong filter type
class MyFilterSet(FilterSet):
is_published = CharFilter() # ❌ WRONG for boolean
// Skip type checking
const data = response as any // ❌ Type assertion workaround
✅ DO
# Proper workflow
git commit "Add category filter tests"
git commit "Add category filter implementation"
git commit "Update frontend to use category filter"
# Use correct filter type
class MyFilterSet(FilterSet):
is_published = BooleanFilter() # ✅ CORRECT
// Fix at source
// Regenerate OpenAPI schema and TypeScript client
// Then types work correctly
Recommended Commit Workflow
Correct sequence:
- Write backend tests →
git commit "Add tests for X" - Implement backend →
git commit "Implement X" - Regenerate OpenAPI schema →
git commit "Update OpenAPI schema" - Update frontend types →
git commit "Update frontend types for X" - Implement frontend →
git commit "Add frontend UI for X"
Questions to Ask Before Implementing
- "Are there API tests for this endpoint?"
- "Do the tests cover all filter combinations?"
- "Does the mock data match the actual API response?"
- "Will this change break any existing tests?"
- "Is the OpenAPI schema up to date?"
- "Have I regenerated the TypeScript client?"
Helpful Commands Reference
Backend
# All tests
cd backend && python manage.py test
# Specific test class
cd backend && python manage.py test jewelry_portfolio.api_test.JewelryAPIIntegrationTest
# Regenerate OpenAPI schema
cd backend && python manage.py spectacular --file openapi_schema.json
Frontend
# All tests (exits after run)
cd frontend && npm run test:run
# Tests with coverage
cd frontend && npm run test:run -- --coverage
# Type check
cd frontend && npm run type-check
# Regenerate TypeScript client
cd frontend && npx @openapitools/openapi-generator-cli generate
Full Validation
# Quick validation script
cd backend && python manage.py test && \
cd ../frontend && npm run type-check && npm run test:run
Key Project Patterns
OpenAPI Schema Sync
When backend changes pagination/endpoints:
- Regenerate schema:
python manage.py spectacular --file openapi_schema.json - Regenerate TS client:
npx @openapitools/openapi-generator-cli generate - Update service layer to use new types
- Update test mocks
Filter Implementation
- Use
BooleanFilterfor boolean fields - Use
NumberFilterfor numeric fields - Test all combinations: single, multiple, edge cases
- Always write tests before implementing
Type Safety
- OpenAPI generator converts snake_case → camelCase
- Use camelCase in TypeScript (e.g.,
isPublishednotis_published) - No type assertions - regenerate schema instead
- Keep service layer interfaces in sync with API
Related Files
- Testing Strategy - Detailed test patterns
- Incident Report - Filter mistakes
- Backend Tests - Example patterns
- Frontend Tests - Component test examples
- CODEBASE_ESSENTIALS.md - Core patterns
Examples
Example 1: Before Committing New Filter
User: "I added a category filter, can I commit?"
Checklist:
- ✅ Backend tests for filter combinations?
- ✅ Used
NumberFilter(not CharFilter)? - ✅ Tested edge cases?
- ✅
python manage.py testpasses? - ✅ Regenerated OpenAPI schema?
- ✅ Frontend tests updated?
- ✅
npm run test:runpasses?
Example 2: Troubleshooting Test Failures
User: "Frontend tests are failing after backend changes"
Steps:
- Check if OpenAPI schema regenerated
- Check if TypeScript client regenerated
- Check if mock data matches new response structure
- Update service layer types
- Update test mocks to match new response
Example 3: Implementing New Endpoint
User: "I need to add a new blog endpoint"
Workflow:
- Write backend tests (GET, POST, PUT, DELETE)
- Implement endpoint
- Run
python manage.py test✅ - Regenerate OpenAPI schema
- Regenerate TS client
- Update frontend service
- Write frontend tests
- Run
npm run test:run✅ - Commit each step
Anti-Patterns
❌ Implementation Before Tests
# Wrong order
git commit "Implement feature"
git commit "Add tests"
❌ Type Assertions as Workarounds
// Wrong - hiding type issues
const data = response as unknown as MyType
❌ Deleting Failing Tests
// Wrong - tests exist for a reason
// test('should validate input', ...) // Commented out
✅ Correct Patterns
# Right order
git commit "Add tests"
git commit "Implement feature"
// Right - fix at source
// Regenerate OpenAPI schema and client
// Right - fix implementation
test('should validate input', () => {
// Update implementation to pass test
})
Converted and distributed by TomeVault — claim your Tome and manage your conversions.