---
title: "Test inconnu"
type: "test-smell"
slug: "unknown-test"
url: "http://localhost:3000/fr/test-smells/unknown-test.md"
category: "Odeurs d'assertion"
description: "Une méthode de test qui exerce le code mais ne contient aucune assertion : elle réussit tant que rien ne lève d'exception, ce qui laisse son objectif réel et ce qu'elle vérifie totalement inconnus."
---
# Test inconnu

> Une méthode de test qui exerce le code mais ne contient aucune assertion : elle réussit tant que rien ne lève d'exception, ce qui laisse son objectif réel et ce qu'elle vérifie totalement inconnus.

## Signs and Symptoms

Un test qui prépare des objets et appelle le système sous test, puis **s'arrête sans la moindre assertion**. Il est vert simplement parce qu'aucune exception n'a été levée — et non parce qu'un comportement attendu a été confirmé. Rien dans le corps n'énonce ce à quoi "correct" ressemble.

Signes révélateurs :

* Aucun `expect`/`assert`/`verify` nulle part dans le corps du test.
* Une "vérification" faite par `console.log`/`print` du résultat qu'un humain est censé examiner à l'œil.
* Un nom de test vague (`testChainDependencies`) et un corps qui ne donne aucun indice sur ce qu'il garantit.
* Le test resterait vert même si la méthode de production renvoyait une valeur complètement erronée.
* Des tests qui reposent entièrement sur "ça n'a pas levé d'exception" sans le dire explicitement.

```js
// Smell : exécute du code, affiche, n'assertte rien — passe quoi que renvoie calculate()
test('chain dependencies', () => {
  const game = Game.newGame(0, '');
  game.setOtherGoods(Building.TOOLMAKERS, 1);
  const logic = new Logic(game);

  const res = logic.calculateChainWithDependencies(Goods.TOOLS);
  console.log(res.toString()); // pas de expect(...) — qu'est-ce que ça vérifie ?
});

```

Une variante courante se cache derrière un mocking massif : le test branche des mocks et appelle le SUT mais n'assertte jamais sur une valeur de retour _ni_ sur les interactions avec les mocks.

## Reasons for the Problem

**Pourquoi cela arrive**

* Un test fictif/TODO a été ébauché ("qu'il compile et s'exécute") et l'assertion n'a jamais été renseignée.
* Un échafaudage de débogage — un `console.log`, une vérification manuelle improvisée — a été committé comme s'il s'agissait d'un test.
* Un refactoring a supprimé ou commenté l'assertion mais a laissé la préparation en place.
* On confond "ça s'exécute sans exception" avec "ça fonctionne". Les tests de fumée sont légitimes, mais ici l'_intention_ de faire un test de fumée n'est jamais rendue explicite.
* Des squelettes de test générés automatiquement ou par IA qui exercent une méthode sans vérifier le résultat.

**Pourquoi c'est nuisible**

* **Fausse confiance.** Le test contribue à la barre verte ainsi qu'à la couverture des lignes et des branches, alors qu'il ne vérifie rien. Les métriques de couverture mentent activement sur le degré de protection du code.
* **Aucune protection contre les régressions.** Le comportement peut se casser silencieusement — mauvaise valeur de retour, mauvais état — et la suite reste verte. C'est la pire espèce de test : il coûte en maintenance et n'attrape rien.
* **Intention inconnue.** Un lecteur (ou un futur mainteneur) ne peut pas dire quel comportement est garanti, et ne peut donc pas modifier le code ou le test en toute sécurité. Il ne documente rien.
* **Érode la confiance dans la suite.** Dès que les gens remarquent des tests qui ne testent pas vraiment, ils cessent de croire que vert signifie bon — ce qui sape aussi tous les autres tests.

C'est l'image inversée de la [Roulette des assertions](#) : ce smell-là comporte _trop_ d'assertions non documentées ; le Test inconnu n'en comporte _aucune_.

## Treatment

Faites en sorte que chaque test énonce ce qu'il attend, et que "il ne doit simplement pas lever d'exception" soit un choix explicite et délibéré.

1. **Ajoutez au moins une assertion sur un résultat observable** — la valeur de retour, l'état résultant ou une erreur levée. Remplacez le débogage par `console.log`/print par un `expect` sur cette valeur.
2. **Si la véritable intention est "ceci ne doit pas lever d'exception", dites-le explicitement** avec `expect(() => fn()).not.toThrow()` (ou `await expect(fn()).resolves.toBeDefined()`). Le test de fumée est alors documenté plutôt qu'accidentel.
3. **Pour les tests d'interaction uniquement**, assertez sur le collaborateur : `expect(mock).toHaveBeenCalledWith(...)`.
4. **Supprimez ou marquez `skip`/`todo` les ébauches mortes** au lieu de laisser un test vert vide (`it.todo('handles chained deps')` consigne honnêtement la lacune sans falsifier la couverture).
5. **Activez un détecteur** (`jest/expect-expect`, `vitest/expect-expect`, ou SonarSource S2699) en CI. Si vous encapsulez vos assertions dans des helpers personnalisés, enregistrez-les via l'option `assertFunctionNames` de la règle pour que les véritables assertions ne soient pas signalées à tort.

```js
// Avant — Test inconnu
test('chain dependencies', () => {
  const logic = new Logic(Game.newGame(0, ''));
  const res = logic.calculateChainWithDependencies(Goods.TOOLS);
  console.log(res.toString());
});

// Après — l'intention et la garantie sont explicites
test('resolves tools to the toolmakers workshop chain', () => {
  const logic = new Logic(Game.newGame(0, ''));
  const res = logic.calculateChainWithDependencies(Goods.TOOLS);
  expect(res).toHaveLength(1);
  expect(res[0].building).toBe(Building.TOOLMAKERS);
});

```

## Detected by

- **eslint-jest** `expect-expect` — jest/expect-expect (https://github.com/jest-community/eslint-plugin-jest/blob/main/docs/rules/expect-expect.md)
- **eslint-vitest** `expect-expect` — vitest/expect-expect (https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/expect-expect.md)
- **sonar** `S2699` — Les tests doivent contenir des assertions (JavaScript) (https://rules.sonarsource.com/javascript/RSPEC-2699/)
- **sonar** `S2699` — Les tests doivent contenir des assertions (Java) (https://rules.sonarsource.com/java/RSPEC-2699/)