What the agent does
The agent inventories the services, interceptors and existing specs before deciding what is missing. In realworld-apps/angular-realworld-example-app, package.json already has a test script that runs vitest, and vitest.config.ts includes src/**/*.spec.ts in a jsdom environment. Services for users, JWT storage, articles, comments, tags and profiles already have spec files. The useful first targets are the interceptors without corresponding specs, followed by any genuinely uncovered service behavior. The task does not assume a blank test suite.
It reads src/app/core/interceptors/token.interceptor.ts, api.interceptor.ts and error.interceptor.ts as separate contracts. The token interceptor gets the current token from JwtService and adds an Authorization value in the form Token followed by that token. The API interceptor prefixes relative requests with https://api.realworld.show/api. The error interceptor clears authentication on a 401 except when the request URL ends with /user, then normalizes the error body and preserves the status. Each condition needs its own observable assertion.
The agent configures TestBed with the real services and interceptors and uses HttpTestingController to observe outgoing requests and provide controlled HTTP responses. Existing comments.service.spec.ts shows the project's TestBed and HTTP testing conventions. New tests check request method, URL and headers, then subscribe to or await the response so the interceptor chain actually executes. JWT tests can use the real localStorage-backed JwtService with cleanup between cases. Replacing the interceptor implementation with a stub would defeat the purpose.
It runs the existing runner non-interactively with bun run test --run. This repository uses Vitest rather than a Karma Chrome launcher, so adding ChromeHeadless flags or introducing another test framework would be unrelated work. Failure cases cover the missing token, ordinary unauthorized requests, the /user exception and normalized network errors where appropriate. The agent verifies that no HTTP request remains outstanding and returns a focused PR without changing authentication behavior to fit its tests.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Inventory this Angular app's services, HTTP interceptors and existing spec files. Add missing unit tests using TestBed and HttpTestingController, prioritizing untested token, URL and error interceptors and any services that truly lack coverage. Exercise real application services and the registered interceptor chain; do not stub the behavior being tested. Assert outgoing URLs, methods and authorization headers, the relevant error and logout branches, and cleanup of storage and pending requests. Reuse the existing runner and run it non-interactively; if the test script is Vitest, use bun run test --run rather than Karma flags. Do not change production behavior. Open a pull request with the added coverage and exact results.",
"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 pull request adds specs beside the relevant Angular source, with small setup changes only where the existing test environment requires them. Its summary identifies which service or interceptor behavior each test protects and names the command used. HTTP assertions show the request after the real interceptor chain has processed it, while response assertions distinguish validation, unauthorized and network failures rather than accepting any thrown error.
Reviewers check the token format, API prefix and /user exception against the application source. They confirm that storage resets and HttpTestingController verification prevent one test from affecting another. A passing jsdom unit suite proves the client behavior it exercises, not the availability or authorization policy of the public backend. The session transcript keeps runner output available alongside the PR's own checks.
Run it on every HTTP client change
Your CI or webhook receiver can start this task whenever a PR changes services or interceptors. Post the body with an API key and replace the repository URL with your connected app, or use the open PR URL to target its branch. Include the changed client behavior in input so the agent fills the current gap instead of regenerating tests for already-covered services.
The use case this job follows, with its automation and trigger: Write the missing tests.
Why run it on Rush?
Interceptor tests involve framework injection, HTTP provider ordering, browser storage and runner setup, even when the source file is short. Rush lets the agent prepare and execute that environment in its own sandbox. It can resolve a test initialization failure without editing the developer's installed packages or leaving a watcher running on their laptop.
The retained command record is useful when a proposed test passes by bypassing the interceptor chain. A reviewer can inspect the setup and output along with the diff, then ask for a follow-up after the turn finishes. Several Angular clients can be checked in separate sessions without sharing their localStorage state or dependency installations.
Frequently asked questions
Does this require Karma or a headless browser?
It follows the test runner already in the app. The inspected example uses Vitest with jsdom, so its non-interactive command is bun run test --run. A different Angular repository may require another command, but the agent should not introduce Karma simply because the task mentions headless execution.
Will it duplicate existing service specs?
No, it inventories both source and specs first. The example already has tests for its user, JWT, article, comment, tag and profile services. The agent adds a distinct uncovered behavior or targets a missing interceptor spec instead of creating a second suite for the same assertions.
Do HTTP unit tests call the live API?
HttpTestingController captures requests inside Angular's testing environment and supplies test responses. That allows exact assertions on client URLs, headers and error handling without changing live data. It does not replace separate integration tests against an actual backend.
Can it test logout behavior without mocking UserService?
The task asks for the real service path and observable authentication effects where the current setup permits them. It can seed and clear JWT storage and inspect resulting requests or state instead of asserting only that a mocked method was called. Any additional initialization traffic must be handled explicitly rather than silently ignored.