Avant d’aller plus loin, si besoin, une clarification quant à la terminologie que l’on utilise :

Terminologie

Structuration d’un cours

Un parcours n’est en réalité qu’un dossier à la structure particulière. L’objectif de ce doc est d’en détailler la structure.

Nous mettons à disposition un repository git d’exemple contenant un parcours d’un seul chapitre avec une seul challenge :

track-boilerplate.zip

Commencez par jeter un coup d’oeil au README :)

Structure de fichier

on retrouve un dossier src à la racine qui contient trois éléments clef :

Structure du dossier fights

Le dossier fights est lui-même composée de sous-dossiers, chacun portant le nom du fight en question. Dans chaque sous-dossier on retrouve un fichier config.json qui définit la configuration d’un fight.

Structure du dossier challenges

Le dossier challenges comporte un sous dossier par challenge. Chaque sous-dossier est nommée avec l’identifiant unique du challenge. Chaque dossier challenge présente la structure suivante :

Le sous dossier Julius d’un dossier challenge

Le sous dossier julius contient un fichier config.json qui indique quel runner utiliser ainsi que quelles options.

Dans 99.9999% des cas il n’y a rien a changer là dedans de votre côté.

Il y a un dossier test dans lequel doivent être placés tous les fichiers de test jest, écris en TS.

L’extension .test.ts est obligatoire pour les tests.

Lorsque julius teste le code il copie le dossier test et copie un cran au dessus la fonction écrite par l’utilisateur.

C’est la raison pour laquelle dans le test d’exemple on importe depuis ...

Si vous voulez créer des fonctions utilitaires pour faciliter le testing, ajoutez les dans le dossier test SANS l’extension .test.ts. Ensuite importez les dans vos tests.

Un cran au dessus on écrit souvent l’implémentation de référence pour tester les tests. Tout ce “cran du dessus” sera remplacé par le contenu du repo de l’utilisateur lors de la correction de Julius