Quelques explications des tests réalisés sur la forge

Ce fichier donne quelques explications sur les tests automatiques exécutés sur les dépôts à l’intérieur de la forge. La plupart des tests sont censés êtres clairs, mais certains sont un peu plus complexes. Cette page donne les explications nécessaires pour reproduire ces tests dans son propre dépôt.

Tests fonctionnels

Tous les tests fonctionnels sont compilés avec l’option -D SET__SIZE=1001, cela même sur les implémentations de taille variable.

Adding consecutive integers in an increasing manner to the brim

Ce test fait les choses suivantes :

  1. Le code est compilé avec -DSET__SIZE=1001

  2. Créer un ensemble vide

  3. Ajouter les entiers de 0 à SET__SIZE-2 (ici 999) dans cet ensemble. Vérifier à chaque fois que l’ajout n’envoie pas d’erreur (il s’agit effectivement du maximum qu’on peut ajouter sans erreur pour l’implémentation sentinel)

  4. Vérifier que la longueur est bien celle attendue à savoir SET__SIZE-1 (ici 1000)

Adding and remove integers to the brim

Ce test fait les choses suivantes :

  1. Le code est compilé avec -DSET__SIZE=1001

  2. Créer un ensemble vide

  3. Ajouter les entiers de 0 à SET__SIZE-2 (ici 999) dans cet ensemble.

  4. Enlever les entiers pairs de 0 à SET__SIZE-2 de cet ensemble.

  5. Vérifier que la longueur est correcte (ici 500).

  6. Ajouter les entiers pairs de 0 à SET__SIZE-2 à cet ensemble.

  7. Vérifier que la longueur est correcte (ici 1000).

Tests de complexité

Il y a 4 tests de complexité, qui consistent à :

  1. Le code est compilé avec -DSET__SIZE=1001,

  2. Créer un ensemble vide

  3. Et ensuite, selon le test :
    • Ajouter les entiers de 0 à 999 dans l’ensemble (add_in_increasing_order)
    • Ajouter les entiers de 999 à 0 dans l’ensemble (add_in_decreasing_order)

  4. A cet instant, le tableau contient 1000 éléments

  5. Ensuite, selon le test :
    • Enlever les entiers de 0 à 999 de l’ensemble (remove_in_increasing_order)
    • Enlever les entiers de 999 à 0 de l’ensemble (remove_in_decreasing_order)

Les valeurs de complexité sont obtenues avec valgrind --tool=callgrind qui permet de calculer le nombre exact d’écritures et de lecture en mémoire effectuées par un programme. Elles sont ensuite comparées aux valeurs obtenues à travers notre implémentation de référence, ramenées à la complexité théorique des algorithmes utilisés pour chaque paire test/implémentation.

Activation et désactivation des tests des implémentations

La forge n’exécute les tests des implémentations que lorsque les répertoires sentinel, dynamic et link sont trouvés. Comme les tests peuvent devenir facilement envahissants au cours du projet, il peut valoir le coup de renommer certains de ces répertoires temporairement. En faisant cela, on ne traite que les tests d’une implémentation à la fois. Pour cela, il est recommandé de faire :

git mv dynamic dynamic.moved  # Disable tests for dynamic
git mv dynamic.moved dynamic  # Re-enable tests for dynamic

FAQ sur les niveaux d’implémentation

Les implémentations évoluent au cours des différents TDs, et les tests sur la forge évoluent aussi. Cela signifie qu’il peut y avoir plus ou moins de tests effectués selon le niveau d’avancement. Il y a en tout 4 niveaux d’implémentation :

  • without * : l’implémentation de départ

  • with * : le constructeur set__empty renvoie un pointeur

  • generic : les données dans les ensembles sont polymorphes (void *)

  • object : le type struct set inclut les fonctions de copie, comparaison et libération du type polymorphe.