---
title: "Test vide"
type: "test-smell"
slug: "empty-test"
url: "http://localhost:3000/fr/test-smells/empty-test.md"
category: "Mauvaises odeurs superflues"
description: "Un test vide est une méthode de test dont le corps ne contient aucune instruction exécutable : il réussit donc toujours tout en ne vérifiant rien."
---
# Test vide

> Un test vide est une méthode de test dont le corps ne contient aucune instruction exécutable : il réussit donc toujours tout en ne vérifiant rien.

## Signs and Symptoms

Un test existe et est signalé comme **réussi**, mais son corps ne contient aucun code exécutable — aucune préparation, aucun exercice, aucune assertion. Formes révélatrices :

```js
// Corps entièrement vide
test('calculates tax', () => {});

// Seulement un commentaire TODO / d'emplacement réservé
it('should reject invalid input', () => {
  // TODO: write this once the API stabilises
});

// Tout est commenté
it('parses the auth header', () => {
  // const result = parse(header);
  // expect(result).toEqual(expected);
});

```

Comment le repérer :

* Le nom du test promet un comportement, mais le corps est `{}`, des espaces, ou uniquement des commentaires.
* Le récapitulatif de votre lanceur de tests affiche le test comme **réussi** (vert), et non ignoré/en attente — c'est ce qui le rend dangereux.
* La couverture de code pour la fonctionnalité nommée est étrangement nulle alors même qu'un « test pour celle-ci » existe.
* Lors de la revue, le diff ajoute un cas de test mais aucun appel à `expect`/`assert`.

Apparenté mais distinct : un test qui prépare et appelle le système sous test mais ne fait **aucune assertion** relève du smell _Test sans assertion / Test inconnu_. Un test vide est le cas plus extrême où le corps est totalement dépourvu d'instructions.

## Reasons for the Problem

**Pourquoi cela arrive**

* Un test a été ébauché comme un emplacement réservé (TDD « écrire d'abord le nom ») et n'a jamais été complété.
* Du code a été commenté pour déboguer un échec ou faire taire un test instable, puis committé et oublié.
* Un générateur/IDE a produit un squelette de test que personne n'a complété.
* Un développeur a voulu « réserver » un nom de test pour plus tard mais a utilisé un corps vide au lieu d'un marqueur todo explicite.

**Pourquoi c'est nuisible**

* **Fausse confiance (le pire aspect).** La plupart des lanceurs de tests signalent un test vide comme _réussi_, et non ignoré. JUnit, Jest, Vitest et consorts afficheront tous du vert pour `test('x', () => {})`. La suite donne l'impression de couvrir le comportement, mais une régression dans le code de production ne sera jamais détectée — c'est sans doute pire que de n'avoir aucun test, car la coche verte induit activement en erreur.
* **Lisibilité.** Un lecteur voit un test nommé `should reject invalid input` et suppose raisonnablement que ce comportement est vérifié. Le nom documente une intention que le corps ne tient jamais.
* **Maintenabilité.** Les tests vides gonflent le nombre de tests et la perception d'une couverture par les noms, masquant de véritables lacunes et rendant difficile de distinguer les emplacements réservés intentionnels des tests abandonnés.
* **Érode la confiance.** Une fois que les contributeurs apprennent que « réussi » ne signifie pas « vérifié », le signal de toute la suite s'affaiblit.

## Treatment

Décidez si le test doit _déjà exister_, puis faites en sorte que le lanceur de tests dise la vérité.

**1\. Si le comportement doit être testé dès maintenant — complétez le corps.** Ajoutez préparation/action/assertion pour qu'il exerce réellement le code :

```js
// Avant — vert, mais ne vérifie rien
test('rounds half up', () => {});

// Après — une véritable attente
test('rounds half up', () => {
  expect(round(2.5)).toBe(3);
});

```

**2\. S'il s'agit d'un véritable emplacement réservé — marquez-le explicitement comme en attente** afin que le lanceur le signale comme todo/ignoré (visible, pas faussement vert) au lieu de laisser un corps vide :

```js
// Avant
it('should reject invalid input', () => {
  // TODO
});

// Après — apparaît comme un todo dans le rapport, jamais comme « réussi »
it.todo('should reject invalid input');   // Jest / Vitest
// ou test.skip(...) / xit(...) avec un ticket de suivi

```

**3\. Si le test est obsolète — supprimez-le.** Un test supprimé est honnête ; un test vide est un mensonge qui coûte en maintenance.

**4\. Restaurez la logique commentée.** Si le corps est entièrement commenté, soit décommentez-le et corrigez-le, soit supprimez le test ; ne livrez jamais du code de test commenté en guise d'« implémentation ».

**5\. Ajoutez un garde-fou.** Activez en CI une règle de lint exigeant la présence d'une assertion (voir les détecteurs) afin que les tests vides/sans assertion fassent échouer le build au lieu de réussir silencieusement.

## Detected by

- **eslint-jest** `expect-expect` — eslint-plugin-jest : expect-expect (signale les tests sans assertion, y compris les corps vides) (https://github.com/jest-community/eslint-plugin-jest/blob/main/docs/rules/expect-expect.md)
- **eslint-vitest** `expect-expect` — eslint-plugin-vitest : expect-expect (impose au moins une attente par test) (https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/expect-expect.md)
- **eslint** `no-empty-function` — ESLint core : no-empty-function (règle générale ; signale le corps de fonction/flèche vide d'un callback de test vide) (https://eslint.org/docs/latest/rules/no-empty-function)
- **sonar** `S2699` — SonarSource : S2699 « Les tests doivent contenir des assertions » (Bloquant ; signale les tests sans assertion et les tests vides ; des équivalents existent pour Java/C#/Python) (https://rules.sonarsource.com/javascript/RSPEC-2699/)
- **pmd** `JUnitTestsShouldIncludeAssert` — PMD (Java) : JUnitTestsShouldIncludeAssert (signale les tests JUnit dépourvus d'assertion, y compris les tests vides) (https://pmd.github.io/pmd/pmd_rules_java_bestpractices.html#junittestsshouldincludeassert)