What the agent does
The agent starts with URL routing and existing coverage, then builds an endpoint checklist. In HackSoftware/Django-Styleguide-Example, styleguide_example/api/urls.py includes authentication, users, errors, files and Google OAuth examples. The project separates API views from services and selectors, so service tests alone do not establish the HTTP contract. The agent reads the views and their tests together to identify which request methods, serializer failures and permission decisions remain untested.
For the users API, styleguide_example/users/apis.py makes the expected cases concrete. UserListApi validates query filters through a serializer and uses LimitOffsetPagination with default_limit = 1. UserDetailApi raises Http404 when user_get returns nothing. UserCreateApi requires email and password, while UserUpdateApi has its own input serializer. The agent uses APIClient requests against real database records to test response fields, invalid inputs, missing records and page boundaries rather than calling serializer methods in isolation.
Authentication coverage must match each view. The users module includes a note that an authenticated version remains to be added, whereas the file APIs inherit ApiAuthMixin. Existing authentication/tests/apis/test_user_login.py already exercises session and JWT login, logout and unauthenticated access to the current-user endpoint. The agent extends those real credential flows and avoids declaring every public endpoint incorrectly protected. For file uploads it reads files/apis.py, checks required metadata and distinguishes local file behavior from external storage or OAuth calls that need separate authorization.
The runner is pytest, with pytest.ini selecting config.django.test. requirements/base.txt pins Django 5.2.7 and Django REST Framework 3.16.1, and docker-compose.yml identifies PostgreSQL as the application database. The agent prepares a disposable database, installs the test dependencies and runs pytest against it. Test settings make Celery tasks eager, so background side effects are considered during setup. The final suite keeps real application views, services and selectors in the path; blocked external integrations are reported rather than replaced by invented success.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "Map this Django REST Framework project's API URLs and existing tests. Add APIClient coverage for every endpoint that lacks it, prioritizing real login/logout, actual permission denials, serializer validation failures, missing records and pagination boundaries. Read each view's permission contract; do not invent authentication requirements for public endpoints. Use the real application services, selectors and a disposable PostgreSQL test database, not mocked modules or fetch. Follow pytest.ini and the existing test settings, account for eager tasks, and do not contact production storage or OAuth accounts. Run focused tests and pytest. Open a pull request with an endpoint coverage checklist, exact results and any externally blocked cases.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
The result is a pull request with endpoint tests placed in the relevant application test directories. Its coverage checklist ties URL and method to the success, validation, permission or pagination behavior exercised. Fixtures create actual database records and obtain credentials through the application where authentication is under test. The report lists the database configuration and commands, and clearly separates API coverage from lower-level service tests already present.
A reviewer checks response bodies as well as status codes, especially error fields and pagination links or results. They confirm that anonymous cases target protected views rather than changing public API policy, and that file tests cannot write to live storage. The session transcript supplies the test output. Missing credentials for external flows or failures in current application behavior remain explicit limitations, not rows marked covered without execution.
Run it on every new DRF endpoint
Have your repository workflow call the sessions API when a PR changes URL patterns, API views or serializers. Put the connected repository or open PR URL in resources and identify the endpoint changes in input. Your service can read the session result after completion or receive a webhook configured on its API key. Keep the endpoint checklist with the PR so the next change extends it instead of creating an unrelated test project.
The use case this job follows, with its automation and trigger: Write the missing tests.
Why run it on Rush?
An endpoint test is most useful when it reaches Django's URL dispatch, permission checks, serializer and database query together. Rush gives the agent its own sandbox to assemble that environment and populate disposable records. It avoids asking the developer to change local database settings or interrupt a running Celery setup just to investigate missing API assertions.
The API turns that investigation into repeatable work per endpoint change. Different repositories can use separate sessions with their own settings and dependency versions. The retained tool results let reviewers inspect whether pytest actually reached PostgreSQL and which integration boundaries remained untested, instead of relying on a generated checklist alone.
Frequently asked questions
Will every endpoint get a missing-auth test?
Only endpoints whose current permission contract requires authentication should reject an anonymous request. The inspected users module and file APIs have different protection. The agent reads those rules before writing assertions, so adding tests does not quietly redefine which routes are public.
Does this test serializers or the full API request?
The main deliverable uses DRF's APIClient to reach the routed view. Validation therefore runs alongside the actual request handling and service calls. Direct serializer tests may already exist, but they do not replace endpoint assertions on status, error body and database effects.
Can it test pagination against real records?
Yes, it creates database records and requests page boundaries using the endpoint's pagination implementation. In the inspected UserListApi, the configured default limit is one, which gives a concrete boundary to exercise. The assertions should cover returned records and continuation behavior rather than just checking that a results key exists.
What happens to uploads and OAuth endpoints?
The agent distinguishes local testable flows from calls that require an external account or storage service. It must not use production credentials or issue consequential external requests without authorization. The PR names those blocked cases and any needed test environment rather than claiming a local database pass verifies external services.