Modern QA2026Element 3: Constraints
Log inJoin
1 / 3 · Book 2 · The Anatomy of a Test-Generation Prompt · drill: interview Q&A⊞ allnext →Get the book →

1.5Element 3: Constraints

Constraints prevent the LLM from generating tests in the wrong framework, language, or style. They also enforce team conventions that make generated code immediately usable.

Essential constraints to specify:

**Constraints:**
- Language: TypeScript 5.x
- Framework: Vitest with supertest
- Pattern: Arrange/Act/Assert with explicit comments
- Naming: "should [behavior] when [condition]"
- No external HTTP calls -- mock all Stripe/SendGrid calls
- Use factory functions from ./tests/factories.ts
- Each test file must import { describe, it, expect } from 'vitest'
- Use beforeEach for test isolation, not beforeAll
- Maximum 25 lines per test function
- No console.log statements in test code

The style reference constraint

One of the most powerful constraints is a style reference: 2-3 existing tests from your codebase that demonstrate the expected patterns.

**Style reference (existing test from our codebase):**
```python
class TestUserCreation:
    def test_should_create_user_when_valid_email(self, db_session, user_factory):
        # Arrange
        dto = user_factory.build(email="new@example.com")

        # Act
        user = UserService(db_session).create_user(dto)

        # Assert
        assert user.id is not None
        assert user.email == "new@example.com"
        assert user.created_at is not None

Follow this exact pattern for all generated tests.


When the AI sees concrete examples, it replicates:
- Class structure with docstrings
- Fixture-based dependency injection (`db_session`, `user_factory`)
- Naming convention: `test_should_X_when_Y`
- Comment markers for Arrange/Act/Assert
- Assertion style (check specific fields, not just status codes)
- Helper usage patterns

> **Pro Tip:** Provide one happy-path test and one error-handling test as style references. This teaches the AI both patterns in one shot.