| name | gen-test |
| description | Generate pytest tests for the GrooveShop Django API following all project conventions: CustomDjangoModelFactory usage, APITestCase with setUpTestData, query counting for N+1 detection, proper authentication patterns, and assertion conventions. Use this skill whenever the user wants to generate tests, write tests, add test coverage, or says things like "test this", "add tests for X", "write tests for the Y endpoint", "generate unit tests", "cover this model with tests". Also use when the user asks to test factories, managers, signals, serializers, or views.
|
| disable-model-invocation | true |
Generate Tests
Generate tests that match every convention in this codebase.
Before You Start
- Identify the target: What are we testing? A model, manager, serializer, viewset, factory, or signal?
- Read the source code of the target module to understand its behavior.
- Read the existing factory for the model (if it exists) — it shows how to create test data.
- Check for existing tests in
tests/unit/{app}/ and tests/integration/{app}/ to match style.
Test File Placement
tests/
├── unit/{app}/ # No DB access or minimal DB (model logic, utils, pure functions)
│ ├── test_models.py
│ ├── test_managers.py
│ ├── test_factories.py
│ ├── test_signals.py
│ └── test_serializers.py
└── integration/{app}/ # Full DB + API client (endpoint tests)
└── test_view_{entity}.py
Naming conventions:
- Test files:
test_{entity}.py or test_view_{entity}.py (for view tests)
- Test classes:
{Entity}ViewSetTestCase, Test{Entity}Factory, Test{Entity}Manager
- Test methods:
test_{action}_{scenario} (e.g., test_list_returns_paginated_results)
What to Generate Per Target Type
| Target | Test Class Base | Key Assertions |
|---|
| Factory | TestCase | Instance created, fields populated, translations exist, get_or_create works |
| Manager | TestCase | QuerySet methods return correct results, for_list()/for_detail() optimize queries |
| Model | TestCase | Validation, computed properties, __str__, save behavior |
| Serializer | TestCase | Field presence, validation errors, read_only enforcement |
| ViewSet (CRUD) | APITestCase | Status codes, response structure, permissions, pagination |
| ViewSet (custom action) | APITestCase | Action-specific logic, permissions, response format |
| Signal | TestCase | Signal fires, side effects occur, async signals use mocks |
For detailed patterns and templates, read references/patterns.md.
Critical Conventions
These conventions are non-negotiable — every generated test must follow them:
- Use factories, never raw
Model.objects.create() for complex objects (factories handle translations, unique fields, and related objects correctly)
- Use
setUpTestData() (class method) for read-only test data; use setUp() only when tests modify data
- Use
reverse() for all URL generation — never hardcode URL paths
- Use
self.client.force_authenticate(user=user) for authentication
- Assert response structure: check
results, count, links keys in list responses
- Assert field presence: verify expected fields exist in response data
- Status code constants: use
status.HTTP_200_OK not 200
- Query counting: use
count_queries fixture or assertNumQueries for manager/view tests
Output Checklist
After generating tests, verify:
