1.1Why Prompt Structure Matters

A poor prompt produces poor tests. This is not a vague principle -- it is a direct, measurable relationship. The difference between "write tests for login" and a structured, context-rich prompt is the difference between a junior engineer guessing and a senior engineer analyzing requirements.

LLMs are statistical pattern matchers. They predict the most likely next token given the input tokens. The quality of their output is directly proportional to the specificity and structure of your input. When you write "write tests for login," the LLM retrieves a generic pattern for login testing from its training data. When you write a structured prompt with context, artifacts, constraints, coverage goals, and output format, the LLM has enough signal to generate tests that are specific to your system, your framework, your coding style, and your coverage needs.

In test generation, this means you need to think of your prompt as a test specification document, not a casual request. Every piece of context you include (or omit) shapes the coverage, quality, and usefulness of the generated tests.

Consider these two prompts and their typical outputs:

Prompt A: The casual request

Write tests for the checkout API.

Typical output from Prompt A:

test('checkout works', () => {
  const result = checkout({ items: [{ id: 1, qty: 1 }] });
  expect(result).toBeDefined();
});

test('checkout fails with empty cart', () => {
  expect(() => checkout({ items: [] })).toThrow();
});

Two tests. Vague assertions. No framework specified. No authentication. No error scenarios. No boundary values. The AI had nothing to work with, so it produced nothing of value.

Prompt B: The structured specification

You are a senior QA engineer. Generate a comprehensive test suite for the
checkout API endpoint.

**Technical Context:**
- Backend: Node.js 20, Express 4, TypeScript
- Endpoint: POST /api/v2/checkout
- Auth: JWT Bearer token with "customer" role
- Database: PostgreSQL 15 via Prisma ORM
- Payment: Stripe API (test mode)
- Prices: stored as integers (cents)

**Acceptance Criteria:**
1. Valid cart with in-stock items creates an order with status "pending"
2. Out-of-stock items return 409 with specific item IDs
3. Invalid payment method returns 402
4. Expired JWT returns 401
5. Missing required fields return 400 with field-specific errors

**Constraints:**
- Framework: Vitest + Supertest
- Pattern: Arrange/Act/Assert with comments
- Naming: "should [behavior] when [condition]"
- Mock all external APIs (Stripe, SendGrid)
- Use factory functions from ./tests/factories.ts

**Coverage goals:**
- All 5 acceptance criteria with at least 1 test each
- At least 2 negative cases per AC
- Boundary values for quantity (0, 1, 100, 101)
- Auth: valid token, expired token, missing token, wrong role

**Output format:**
- Single TypeScript file
- One describe block per AC
- One it block per test case

Typical output from Prompt B: 25-35 well-structured tests covering every acceptance criterion, edge case, and boundary value, using the correct framework, following the specified naming convention, and ready to drop into the test directory.

The difference is not subtle. It is the difference between wasted time and productive output.