Dépôts et tests automatiques

Vous disposez d’un dépôt git individuel hébergé sur la machine thor, qui lance régulièrement des tests automatiques pour vérifier vos mises en œuvre et vous aider à y découvrir des bugs que vos propres tests ne parviendraient pas à détecter.

Organisation du dépôt

Votre dépôt doit impérativement suivre l’organisation ci-dessous pour le bon fonctionnement des tests automatiques. Votre Makefile doit proposer une règle build qui compile votre code (et qui ne fait que cela), et une règle test qui lance vos tests. Vous pouvez bien sûr ajouter d’autres règles.

Votre dépôt a été initialisé avec certains des fichiers mentionnés ci-dessous. Les autres fichiers seront ajoutés au fur et à mesure des séances.

Makefile
set/
-- set.h
-- test_set_func.c
sentinel/
-- set_sentinel.h
-- set_sentinel.c
-- test_sentinel_struc.c
dynamic/
-- set_dynamic.h
-- set_dynamic.c
-- test_dynamic_struc.c
link/
-- link.h
-- link.c
-- set_link.h
-- set_link.c
-- test_link.c (tests structurels de link.c/h)
-- test_link_struc.c (tests structurels de set_link.c/h)

Tests automatiques

Sur thor, en plus de vos tests, nous exécutons deux séries de tests “Functional tests for” et “Structural tests for”.

Ces tests sont exécutés à chaque fois que vous déposez du code sur votre dépôt via la commande git push. Votre travail n’est pas évalué : ces tests sont purement indicatifs. La validation de tous nos tests est cependant un objectif à atteindre.

Cet enseignement a également pour objectif d’apprendre à écrire des tests: vous ne devez donc pas vous contenter d’utiliser nos propres tests. Pour éviter cela : un délai de latence ne permet pas de lancer nos tests trop régulièrement, et les cas de tests ne sont pas explicites. Lorsqu’un de nos tests échoue, vous devez donc écrire votre propre test pour reproduire le problème. Si vous n’y parvenez pas, n’hésitez pas à solliciter votre encadrant(e) qui pourra vous y aider.

Les tests évoluent au fur et à mesure des séries d’exercices (changements d’API). Il est donc possible que les tests qui passent à un certain moment ne passent plus ensuite, temporairement.

Plus d’informations sur les tests sont données sur la page suivante.

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.

Pour le dernier niveau d’implémentation, le type struct set a le prototype suivant (ici pour l’implémentation sentinel) :

struct set{
  void* s[SET__SIZE];
  int (*cmp)(const void*, const void*);
  void * (*copy)(void const *);
  void (*del)(void *);
};

Et le constructeur set__empty a le prototype :

struct set * set__empty(int (*cmp)(const void*, const void*),
                        void * (*copy)(void const *),
                        void (*del)(void *));