Prompt ChatGPT pour écrire des tests : générez des tests unitaires et d'intégration rapidement

L’écriture de tests est la tache que les développeurs sautent le plus souvent — et qu’ils regrettent le plus d’avoir sautée. La principale barrière n’est pas la complexité mais la monotonie : identifier les cas limites, configurer les mocks et écrire les memes patterns d’assertion encore et encore. Ce prompt délègue ce travail répétitif a ChatGPT tout en vous laissant le controle sur ce qui est testé et comment. Vous fournissez le code et votre stack de test, et le modèle génère une suite de tests complète couvrant le chemin nominal, les cas limites et les scénarios d’erreur.

Le prompt

You are a senior test engineer. Write a comprehensive test suite for the code below. The tests must be production-ready: properly structured, covering real edge cases, and using idiomatic patterns for the specified testing framework.

**Language/Framework**: [LANGUAGE_AND_FRAMEWORK]
**Testing framework**: [JEST / PYTEST / GO_TESTING / VITEST / MOCHA / JUNIT / ETC]
**Code to test**:
[PASTE_YOUR_CODE]

**What this code does**: [ONE_LINE_DESCRIPTION]

Requirements:
1. **Test categories** — Organize tests into these groups:
   - Happy path: standard inputs that should succeed
   - Edge cases: boundary values, empty inputs, null/undefined, max values
   - Error cases: invalid inputs, expected failures, error messages
   - (If applicable) Integration: tests that verify interaction with external dependencies

2. **For each test**:
   - Use a descriptive test name that states the expected behavior (e.g., "returns 404 when user does not exist")
   - Include arrange/act/assert structure
   - Add a brief inline comment only when the test setup is non-obvious

3. **Mocking strategy**: 
   - Mock external dependencies (database, APIs, file system)
   - Do NOT mock the code under test
   - Use the mocking tools native to the testing framework

4. **Coverage targets**:
   - Every public function/method must have at least one test
   - Every conditional branch must be exercised
   - Every thrown error or returned error must be tested

Do not write explanatory text between tests. Just the code, properly organized with describe/context blocks.

Comment utiliser ce prompt

1. Copiez le prompt ci-dessus
2. Remplacez les variables :
   • [LANGUAGE_AND_FRAMEWORK] : ex. “TypeScript / Express” ou “Python 3.12 / FastAPI”
   • [JEST / PYTEST / ...] : votre framework de test
   • [PASTE_YOUR_CODE] : la fonction, classe ou module a tester
   • [ONE_LINE_DESCRIPTION] : ce que fait le code (ex. : “Validates and processes user registration”)
3. Collez dans ChatGPT (GPT-4o pour les meilleurs résultats)
4. Relisez les tests générés : vérifiez que les mocks correspondent a vos vraies dépendances et que les cas limites sont pertinents pour votre domaine
5. Lancez les tests et corrigez les chemins d’import ou configurations de mocks spécifiques a votre projet

Exemple de résultat

Entrée

Language/Framework: TypeScript / Express
Testing framework: Vitest
Code to test:
export function validateEmail(email: string): { valid: boolean; reason?: string } {
  if (!email) return { valid: false, reason: "Email is required" };
  if (email.length > 254) return { valid: false, reason: "Email too long" };
  const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  if (!regex.test(email)) return { valid: false, reason: "Invalid format" };
  return { valid: true };
}

What this code does: Validates an email string and returns a result object with a reason on failure.

Sortie

import { describe, it, expect } from "vitest";
import { validateEmail } from "./validation";

describe("validateEmail", () => {
  // Happy path
  describe("valid emails", () => {
    it("accepts a standard email address", () => {
      const result = validateEmail("[email protected]");
      expect(result).toEqual({ valid: true });
    });

    it("accepts email with subdomain", () => {
      const result = validateEmail("[email protected]");
      expect(result).toEqual({ valid: true });
    });

    it("accepts email with plus addressing", () => {
      const result = validateEmail("[email protected]");
      expect(result).toEqual({ valid: true });
    });
  });

  // Edge cases
  describe("boundary values", () => {
    it("accepts email at exactly 254 characters", () => {
      const localPart = "a".repeat(243);
      const email = `${localPart}@example.com`;
      expect(email.length).toBe(254);
      expect(validateEmail(email).valid).toBe(true);
    });

    it("rejects email at 255 characters", () => {
      const localPart = "a".repeat(244);
      const email = `${localPart}@example.com`;
      expect(email.length).toBe(255);
      expect(validateEmail(email)).toEqual({
        valid: false,
        reason: "Email too long",
      });
    });
  });

  // Error cases
  describe("invalid inputs", () => {
    it("rejects empty string", () => {
      expect(validateEmail("")).toEqual({
        valid: false,
        reason: "Email is required",
      });
    });

    it("rejects email without @ symbol", () => {
      expect(validateEmail("userexample.com")).toEqual({
        valid: false,
        reason: "Invalid format",
      });
    });

    it("rejects email without domain", () => {
      expect(validateEmail("user@")).toEqual({
        valid: false,
        reason: "Invalid format",
      });
    });

    it("rejects email with spaces", () => {
      expect(validateEmail("user @example.com")).toEqual({
        valid: false,
        reason: "Invalid format",
      });
    });

    it("rejects email without TLD", () => {
      expect(validateEmail("user@example")).toEqual({
        valid: false,
        reason: "Invalid format",
      });
    });
  });
});

Pourquoi ce prompt fonctionne

La structure en quatre catégories (chemin nominal, cas limites, cas d’erreur, intégration) prévient le défaut classique ou ChatGPT génère cinq tests de chemin nominal et considère le travail terminé. Les cas limites et les scénarios d’erreur sont la ou les vrais bugs se cachent, et les exiger explicitement produit une suite de tests bien plus utile.

Exiger des noms de tests descriptifs force le modèle a raisonner sur le comportement attendu plutot que sur les détails d’implémentation. Un test nommé “returns 404 when user does not exist” est a la fois de la documentation et un garde-fou de régression. Un test nommé “test3” n’est ni l’un ni l’autre.

La contrainte de stratégie de mocking empeche ChatGPT de générer des tests qui mockent le code sous test — une erreur étonnamment fréquente dans les tests générés par IA qui fait passer les tests tout en ne testant rien de réel. Spécifier ce qui doit et ne doit pas etre mocké maintient l’honneteté des tests.

Variantes

Pour tester des endpoints API

You are a senior test engineer. Write integration tests for the following API endpoint using [TESTING_FRAMEWORK] and [HTTP_CLIENT — e.g., supertest].

**Endpoint code**:
[PASTE_ROUTE_HANDLER]

**Database model**:
[PASTE_MODEL_DEFINITION]

Write tests for:
- Successful creation/read/update/delete (happy path)
- Validation failures (missing fields, invalid types, too-long values)
- Auth scenarios (unauthorized, forbidden, expired token)
- Concurrent requests (if applicable)
- Response shape assertions (status code, headers, body structure)

Use a test database setup/teardown pattern. Do not mock the database — use a real test database.

Pour tester des composants React

You are a senior frontend test engineer. Write tests for the following React component using [TESTING_LIBRARY / VITEST / JEST].

**Component**:
[PASTE_COMPONENT_CODE]

**Props interface**:
[PASTE_PROPS_TYPE]

Write tests for:
- Renders correctly with required props
- Renders correctly with all optional props
- User interactions (clicks, form inputs, keyboard events)
- Conditional rendering (loading state, error state, empty state)
- Accessibility: focusable elements, ARIA attributes, screen reader text

Use @testing-library/react. Prefer `getByRole` and `getByLabelText` over `getByTestId`. Never test implementation details.

Conseils pour de meilleurs résultats

• Collez les types et interfaces en plus du code. ChatGPT écrit de bien meilleurs tests de cas limites quand il connait la forme exacte des entrées et sorties.
• Précisez les conventions de mocking de votre projet. Si vous utilisez l’injection de dépendances, dites-le. Si vous utilisez vi.mock() pour le module mocking, mentionnez-le. Cela évite que le modèle ne devine mal.
• Demandez a ChatGPT de générer un test pour un cas limite spécifique quand vous repérez une lacune. Dites “Add a test for when the database connection times out during user creation” pour combler les trous de la suite générée.

Prompts associés

• ChatGPT Prompt for Debugging Errors
• ChatGPT Prompt for Code Review
• What is Chain-of-Thought Prompting?
• Prompt Engineering Guide