Génère des tests unitaires complets pour le module suivant.

<fichier-a-tester>
[Chemin du fichier à tester]
</fichier-a-tester>

<contexte>
[Optionnel: décris le rôle du module, ses dépendances, les cas d'utilisation principaux]
</contexte>

Suis ces instructions:

<etape-1-analyse>
1. Lis le fichier source et identifie toutes les fonctions/méthodes exportées
2. Pour chaque fonction, identifie:
   - Les paramètres et leurs types
   - Le type de retour
   - Les branches conditionnelles (if/else, switch, ternaires)
   - Les cas d'erreur (throw, reject, retours null/undefined)
   - Les dépendances externes (imports, appels API, base de données)
</etape-1-analyse>

<etape-2-generation>
Crée un fichier de test avec cette structure:

import { describe, it, expect, vi, beforeEach } from 'vitest'

Pour chaque fonction exportée, crée un bloc describe avec:

1. Cas nominaux (happy path):
   - "devrait [résultat attendu] quand [condition normale]"
   - Un test par comportement distinct

2. Cas limites:
   - Entrées vides (string vide, tableau vide, objet vide)
   - Valeurs nulles et undefined
   - Nombres: 0, négatifs, très grands, décimaux, NaN, Infinity
   - Strings: caractères spéciaux, Unicode, très longues
   - Tableaux: un seul élément, doublons, ordre inversé

3. Cas d'erreur:
   - Types incorrects (si pas protégé par TypeScript au runtime)
   - Erreurs réseau simulées (si appels externes)
   - Timeouts (si opérations async)

4. Cas de régression:
   - Si le contexte mentionne des bugs passés, ajoute un test spécifique
</etape-2-generation>

<conventions>
- Noms de tests en français, descriptifs: "devrait retourner un tableau vide quand l'entrée est null"
- Un seul assert par test (sauf vérification d'objet)
- Utilise vi.fn() et vi.mock() pour les dépendances externes
- Utilise beforeEach pour réinitialiser l'état entre les tests
- Pas de dépendance à l'ordre d'exécution entre les tests
- Pas de données de test en dur dans les tests: utilise des factories ou des constantes nommées
- Groupe les tests par comportement, pas par implémentation
</conventions>

<exemple-structure>
describe("formatPrice", () => {
  describe("cas nominaux", () => {
    it("devrait formater un prix entier avec le symbole euro", () => {
      expect(formatPrice(1000)).toBe("10,00 €")
    })

    it("devrait formater un prix avec centimes", () => {
      expect(formatPrice(1050)).toBe("10,50 €")
    })
  })

  describe("cas limites", () => {
    it("devrait retourner '0,00 €' pour un montant de zéro", () => {
      expect(formatPrice(0)).toBe("0,00 €")
    })

    it("devrait gérer les montants négatifs", () => {
      expect(formatPrice(-500)).toBe("-5,00 €")
    })
  })

  describe("cas d'erreur", () => {
    it("devrait lancer une erreur pour NaN", () => {
      expect(() => formatPrice(NaN)).toThrow()
    })
  })
})
</exemple-structure>

Après la génération, lance les tests et vérifie qu'ils passent (sauf ceux qui révèlent de vrais bugs).