
# Directives générales de rédaction des tests


Il est important de tester non seulement les interfaces de l'implémentation mais aussi les résultats produits par cette implémentation pour s'assurer qu'elle fonctionne correctement et répond aux spécifications définies. Par exemple:
- si une fonction retourne un entier, vérifie qu'il est correctement calculé
- si une fonction retourne un dataframe, vérifie que son contenu correspond bien à ce qui est attendu (nombre de lignes, nombre de colonnes, valeurs contenues dans les colonnes)
- si une fonction retourne une chaine de caractères, vérifie que cette chaine correspond bien à ce qui est attendu (format, contenu) si une fonction retourne un tuple, vérifie que ses composantes sont cohérentes avec les valeurs d'entrée et les spécifications de la fonction
- élargis ce principe à toutes les structures de données calculées par les fonctions ou méthodes que tu testes.


Les tests doivent permettrent un taux de couverture de 100% du code si c'est possible. Vérifier systématiquement ce taux de couverture après chaque exécution des jeux de tests et compléter les tests pour atteindre ce taux de couverture de 100%.

Après avoir passé tous les test, créer un rapport d'exécution qui précise que:
- tous les tests prévus ont été exécutés et ont réussi, si c'est le cas bien sûr, sinon indiquer quels tests ont échoué et pourquoi
- donne la durée d'exécution pour chaque groupe de tests, et la durée d'exécution pour l'ensemble des tests
- indique le taux de couverture global de la procédure de tests, qui doit être de 100% si tu as suivi les directives ci-dessus. Si ce n'est pas possible, décris les parties du code où ça ne l'est pas (pas besoin de lister les lignes, une brêve description suffit) ne l'est pas et pourquoi ça ne l'est pas.

Je te laisse choisir la forme du rapport, du moment que c'est clair, concis et facilement lisible par un humain. Je veux par contre qu'il soit enregistré dans le dossier des tests. Il servira de preuve à la bonne exécution des tests et pourra être consulté à tout moment pour vérifier que les tests ont bien été exécutés et qu'ils ont réussi. Rédige ce rapport en anglais.

Enfin, je veux que tu écrives la commande pour exécuter les tests et générer le rapport d'exécution. Cette commande doit être facilement exécutable dans un terminal, et doit permettre de lancer tous les tests et de générer le rapport d'exécution en une seule commande. Je te laisse choisir la forme de cette commande, du moment qu'elle est claire, concise et facilement exécutable. Tu nommeras cette commande "runtests" et tu l'ajouteras dans le fichier des instructions pour les tests, de manière à ce qu'elle soit facilement accessible et réutilisable à tout moment.


# Directives particulières de rédaction des tests

Cette sectiondonne des directives spécifiques **supplémentaires** pour tester certaines fonctions qui te guideront dans l'application du principe général ci-dessus. Ne te limite **surtout pas** à ces directives spécifiques, elles sont là pour t'aider à aller plus loin dans tes tests, pas pour te restreindre.

## Tests de make_calendar_table

Tu n'insères que deux périodes dans l'ensemble de tes tests pour make_calendar_table. Or on sait que les bug dans des listes ou des tables se produisent dans trois cas de figure:
- le premier élément de la liste/table
- le dernier élément de la liste/table
- un élément intermédiaire de la liste/table

Prends soin de tester ces trois cas de figure.

D'autre part il ne suffit pas de vérifier que la méthode retourne un DataFrame Polars, il faut aussi vérifier que les données contenues dans ce DataFrame sont correctes et correspondent bien aux périodes qui ont été créées. 

## Tests de make_period_id

Pour la méthode make_period_id, il ne suffit pas de vérifier que la méthode retourne un PeriodId, il faut aussi vérifier que cet identifiant correspond bien à la période d'entrée. 

Vérifie que les periodId sont bien encodés lorsque l'on fournit des périodes d'entrée qui ne sont pas entre les bornes prévues. On doit non seulement être capable d'encoder de telles périodes, mais il faut aussi vérifier qu'elles sont correctement décodées.

## Tests de get_period_range

Pour get_period_range, il ne suffit pas de vérifier que la méthode retourne un tuple de deux éléments, il faut aussi vérifier que ces éléments correspondent bien au début et à la fin de la période identifiée par le PeriodId d'entrée.

---

# Exécution de la suite de tests

Deux façons d'exécuter la suite de tests:
- depuis la racine du projet en utilisant la commande powershell "./runtests.ps1"
- depuis la racine du projet en lançant Python et le script adapté: python tests/runtests.py

