Organisation des tests publicodes dans les modèles

[m-maillot]

Etat de l'art

Les tests sont situés dans le __tests__ à la racine du projet.

Il y a deux nomenclatures de fichiers:

• depart.(mise.)retraite.(intitulé.cc).spec.ts

Ce fichier contient les tests sur les résultats du départ et/ou de la mise à retraite pour une CC.

Note : Il peut contenir aussi les tests sur les notifictions à afficher.

• depart.(mise.)retraite.(intitulé.cc).references.spec.ts

Ce fichier va contenir les tests sur les références que l'on va retourner avec le calcul.

On peut distinguer 3 types de tests :

• tests sur les résultats
• tests sur les notifications
• tests sur les références

Pour le simulateur de préavis à la retraite, on a un découpage dans le cas où c'est un départ ou une mise à la retraite. Ce découpage est grandement inspiré par la structure du fichier Excel.
Dans notre cas, on va placer les tests pour les 2 cas dans le même fichier par défaut et les séparer si ce dernier devient trop indigeste.

On retrouve également quelques fichiers de tests particuliers:

• extract.implemented.cc.spec.ts: Permet de valider le script qui extrait les CC depuis publicode pour avoir l'ensemble des CC implémentés.
• check.rule.title.spec.ts: Permet de valider que l'ensemble des données manquantes pour les CC possède un titre avec un type cdtn.

Proposition

Etape 1

La première proposition consiste à regrouper dans un dossier par CC avec le découpage par type de test.

___test___
  /legal
     depart.mise.retraite.specs.ts
  /batiment.etam
     depart.mise.retraite.specs.ts
     depart.mise.retraite.references.specs.ts
     depart.mise.retraite.notifications.specs.ts

Etape 2

Avec l'arrivé de nouveau simulateur, on peut passer organiser également par simulateur.

___test___
  /legal
     /preavis.retraite
        depart.mise.specs.ts
  /batiment.etam
     /preavis.retraite
       depart.mise.specs.ts
       references.specs.ts
       notifications.specs.ts

Etape 3

On peut également se dire que c'est plus logique de regrouper totalement par cas (départ / mise)

___test___
  /legal
     /preavis.retraite
        references.constants.ts
        depart.specs.ts // contient également les tests des notifs et références pour le départ
        mise.specs.ts
  /batiment.etam
     /preavis.retraite
       references.constants.ts // contient les références de la CC si le départ et la mise à la retraite en partage certain
       depart.specs.ts
       mise.specs.ts

Avantages: pourvoir utiliser nos cas de tests pour valider les références et les notifications en même temps. A voir si ça ne complique pas trop les tests...

Etape 4

On peut se dire qu'un seul fichier suffit ou que c'est à la décision au dév au moment de l'implémenter

___test___
  /legal
     /preavis.retraite
        references.constants.ts
        depart.mise.specs.ts // test léger, on a un seul fichier
  /batiment.etam
     /preavis.retraite
       references.constants.ts 
       depart.specs.ts // test plus lourd, on divise
       mise.specs.ts
  /batiment.etam
     /preavis.retraite
       references.constants.ts 
       depart.cadre.specs.ts // test vraiment lourd !
       depart.etam.specs.ts 
       mise.specs.ts

@maxgfr @carolineBda Je vous laisse commenter / ajouter vos propositions :)

[m-maillot]

Concernant le nommage, actuellement on a 3 types de nommage:

• PascalCase pour le code (MyFile.tsx)
• SnakeCase pour les modèles (ma_convention.yaml)
• DotCase (connais pas le vrai nom) pour les tests (mon.test.spec.ts)

Je propose de passer les tests en snake case comme pour les modèles.

On a également un mélange de français et anglais au niveau des tests.

Je propose que l'on utilise le français dans les tests

[maxgfr]

Pour le nommage, je pense qu'il faudrait se baser sur : https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines

Le PascalCase est utilisé pour les types, par conséquent pour le nom des variables dans le code, il faudrait utiliser le camelCase

Concernant le nommage des fichiers de tests ou du code, je propose plutôt le kebab-case (non pas car je promeus la consommation de mets turcs), ce commentaire résume bien le choix : https://stackoverflow.com/a/44882336/6491071

[carolineBda]

Je préfère aussi beaucoup plus kebab-case dans tous les noms de fichiers (jamais de majuscules)

[m-maillot]

On part sur du hyphens-case (kebab-case) par défaut et du PascalCase si c'est composant react (même pour les tests) pour le nommage des fichiers.
On sur sur du hyphens-case pour le nommage des dossiers.

[maxgfr]

Merci @m-maillot pour ce résumé des possibilités d'architecture de découpage des tests pour les simulateurs.

Pour ma part, le principe ci-dessous me convient parfaitement :

___test___
  /legal 
     /preavis-retraite
        references.spec.ts  # Je pense qu'on peut merge les constants avec les tests sur les références du fait que les constants ne sont jamais import
        depart.mise.specs.ts // test léger, on a un seul fichier # Super suggestion
  /batiment-etam
     /preavis.retraite
       references.spec.ts 
       depart.specs.ts // test plus lourd, on divise # Absolument d'accord aussi
       mise.specs.ts

C'est la méthode la plus scalable, lorsqu'on ajoutera des CC ou de nouveaux simulateurs

[carolineBda]

Parfait pour moi aussi. Juste pas fan du __test__, on mettrait juste test ?

[m-maillot]

Je suis d'accord, et on change le pattern pour *.specs.ts

[carolineBda]

Il faudrait grouper les test de même famille pour un affichage des résultats plus clair :

 describe("Départ à la retraite", () => {
    test("Pour un employé possédant 4 mois d'ancienneté, son préavis devrait être 2 mois",
     [...]
    test("Pour un employé possédant 18 mois d'ancienneté, son préavis devrait être 2 mois",
     [...]
  });

Autre point, on ne devrait éviter d'utilisé de condition dans le corps du test, parce que cette dernière n'est elle même pas testé donc on ne peut pas garantir son bon fonctionnement.

[m-maillot]

If interdit dans le code.

[maxgfr]

@m-maillot @carolineBda Pourquoi renommer les fichiers de convention collective par leur IDCC, c'est plus simple à retrouver que par nom, vous en pensez quoi ?

[carolineBda]

Moi ça me va. C'est ce qu'on a fait sur les simu en js non ?

[m-maillot]

Du coup, on n'avait pas discuté de ce point dans mes souvenirs... C'est un point intéressant car l'idcc permettrait de s'y retrouver facilement en effet :)

[maxgfr]

Du coup, quid de la pr #3897 de @carolineBda ?