| name | developer-checklist |
| description | Pre-commit and pre-push validation checklist for gnwebsite fullstack project. Use when implementing features, writing tests, before committing code, or creating pull requests. Ensures backend Django tests pass, frontend Vitest tests pass, TypeScript validates, and code follows project patterns. Includes filter implementation, API contract alignment, and test troubleshooting. |
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):
npm run test:run
npm test
npm run test
Backend Tests
cd backend && python manage.py test
cd backend && python manage.py test jewelry_portfolio.api_test.JewelryAPIIntegrationTest
Backend Feature Implementation Checklist
New Model/Field
New Endpoint
New Filter
Model Changes
Frontend Feature Implementation Checklist
API Integration
Component Updates
After Backend API Changes
Pre-Commit Checklist
Run BEFORE every commit:
Pre-Pull Request Checklist
Before creating ANY pull request:
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
git commit "Add category filter to frontend"
class MyFilterSet(FilterSet):
is_published = CharFilter()
const data = response as any
✅ DO
git commit "Add category filter tests"
git commit "Add category filter implementation"
git commit "Update frontend to use category filter"
class MyFilterSet(FilterSet):
is_published = BooleanFilter()
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
cd backend && python manage.py test
cd backend && python manage.py test jewelry_portfolio.api_test.JewelryAPIIntegrationTest
cd backend && python manage.py spectacular --file openapi_schema.json
Frontend
cd frontend && npm run test:run
cd frontend && npm run test:run -- --coverage
cd frontend && npm run type-check
cd frontend && npx @openapitools/openapi-generator-cli generate
Full Validation
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
BooleanFilter for boolean fields
- Use
NumberFilter for 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.,
isPublished not is_published)
- No type assertions - regenerate schema instead
- Keep service layer interfaces in sync with API
Related Files
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 test passes?
- ✅ Regenerated OpenAPI schema?
- ✅ Frontend tests updated?
- ✅
npm run test:run passes?
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
git commit "Implement feature"
git commit "Add tests"
❌ Type Assertions as Workarounds
const data = response as unknown as MyType
❌ Deleting Failing Tests
✅ Correct Patterns
git commit "Add tests"
git commit "Implement feature"
test('should validate input', () => {
})