How do I set up a unit test assistant for generating deterministic tests in our JavaScript repo?

A good way to set up a unit test assistant for a JavaScript repo is to make it a deterministic test generator: it should follow strict rules, inspect the code, and output tests in a consistent style every time.

1) Decide what the assistant is allowed to do

Keep the assistant narrowly scoped:

• Generate unit tests only
• Use your repo’s test stack, e.g.:
  • Jest
  • Vitest
  • Mocha/Chai
• Prefer existing patterns in the repo
• Avoid flaky behavior:
  • no real network calls
  • no real timers unless explicitly mocked
  • no randomness unless seeded/mocked
  • no filesystem or DB access unless mocked

2) Define deterministic rules

Put these rules in the assistant prompt/instructions.

Example rules:

• Always inspect existing test files before writing new ones
• Match the repo’s test framework and style
• Use fixed timestamps, IDs, and random values
• Mock all external dependencies
• Do not invent APIs or behavior not present in source code
• If behavior is unclear, ask clarifying questions instead of guessing
• Generate tests that are idempotent and order-independent

3) Use a strict prompt template

Example system prompt for the assistant:

You are a unit test generator for a JavaScript repository.

Goals:
- Generate deterministic unit tests only.
- Follow the existing test framework and file conventions in the repo.
- Base tests strictly on the provided source code and existing test patterns.
- Mock all external dependencies, time, randomness, network, and filesystem access unless the request explicitly says otherwise.
- Do not write integration tests, snapshot tests unless already used in the repo, or tests for behavior not supported by the code.

Rules:
1. Use the repo's testing library and assertion style.
2. Preserve naming conventions, folder structure, and import style.
3. Make all tests deterministic:
   - mock Date, Math.random, UUIDs, timers, fetch, HTTP clients, and env-dependent values when needed.
4. Cover:
   - happy path
   - edge cases
   - error handling
5. Do not change production code unless explicitly requested.
6. If code behavior is ambiguous, ask questions instead of assuming.
7. Output only the test file content unless asked otherwise.

4) Give the assistant enough context

For best results, feed it:

• the source file under test
• related helpers/types
• existing test examples
• package.json
• test config if relevant
• lint/format rules if they affect output

A good input bundle looks like:

• src/foo.js
• src/foo.test.js examples
• package.json
• jest.config.js or vitest.config.ts
• any mocking helpers already used in the repo

5) Make generation deterministic in code

If you’re building this assistant into a tool, reduce variability:

• Set model generation to temperature 0
• Use a fixed prompt template
• Normalize inputs:
  • sort file lists
  • include only relevant files
  • strip irrelevant noise
• Ask for one file at a time or one module at a time
• Validate output with:
  • formatter
  • linter
  • test runner

6) Add a verification loop

Have the assistant generate tests, then automatically run:

• formatter
• lint
• unit test command
• coverage check if desired

If tests fail:

• feed error output back to the assistant
• ask it to minimally patch the generated tests

7) Recommended workflow

A practical flow:

1. User selects a source file
2. Assistant reads:
   • source file
   • nearby tests
   • config
3. Assistant generates a test file
4. CI runs the tests
5. Failures are sent back for correction

8) Example test-generation prompt

You can use something like:

Generate deterministic unit tests for the following JavaScript module.

Constraints:
- Use the existing test framework in this repo.
- Do not introduce flaky behavior.
- Mock external dependencies.
- Use fixed values for time, randomness, and UUIDs.
- Follow the style of the existing tests in this repository.
- Cover normal behavior, edge cases, and thrown errors.
- Output only the test file.

Source file:
[PASTE FILE HERE]

Existing tests:
[PASTE RELEVANT EXAMPLES HERE]

Test config:
[PASTE CONFIG IF NEEDED]

9) If you want higher reliability

Add a few guardrails:

• A schema for output file paths and contents
• A diff-only mode
• A “no speculative APIs” rule
• A test plan before code generation for complex files

10) Minimal implementation idea

If you’re wiring this into a repo tool:

• CLI command: generate-test path/to/module.js
• It gathers relevant context
• Sends it to the model with temperature 0
• Writes the output to module.test.js
• Runs tests
• Patches failures automatically

If you want, I can also give you:

1. a ready-to-use system prompt,
2. a Node.js CLI example, or
3. a repo-specific setup for Jest/Vitest.