[TECH] Enlever l'injection des sérialisers dans les controlleurs (devcomp)

[bpetetot]

🚙 Problème

Parfois on utilise directement les serializers dans les controlleurs, parfois on les injecte dans un attribut dependencies.

Mais les serialisers sont des fonctions pures (déterministes et sans effet de bord), il y a peu d'intérêt de les injecter et mocker dans les tests unitaires.

🍃 Proposition

Il y a peu d'utilité à cette injection, je propose de simplifier et directement utiliser les serialisers dans les contrôleurs (sans injection).

Bounded contexts dans cette PR dont on a modifié les controllers:

• devcomp

Important

Ça change la façon dont sont fait les tests unitaires des controlleurs. On ne peut plus mocker par des Symbol les entrée/sortie des sérialisers.
C'est compréhensible de souhaiter cette façon de faire, donc on peut ne pas merger cette PR si vous souhaitez conserver cette méthode de test. L'avantage est que le test n'est pas indépendant du modèle, mais l'inconvénient est qu'on test l'implémentation plutôt que le comportement.
Est-ce que les controlleurs devraient avoir des tests unitaires? Est-ce que ces tests ne sont pas déjà couvert pas les tests d'acceptance de la couche application ?

🦵 Remarques

Scout: on en profite pour simplifier l'export des controlleurs en exportant directement l'objet du controlleur.

🔗 Pour tester

CI Ok

[pix-bot-github]

Choisir les applications à déployer :

• API | 👩‍💻 Dashboard Scalingo
• App (.fr) – App (.org) | 👩‍💻 Dashboard Scalingo
• Orga (.fr) – Orga (.org) | 👩‍💻 Dashboard Scalingo
• Certif (.fr) – Certif (.org) | 👩‍💻 Dashboard Scalingo
• Junior | 👩‍💻 Dashboard Scalingo
• Admin | 👩‍💻 Dashboard Scalingo
• API MaDDo | 👩‍💻 Dashboard Scalingo
• Audit Logger | 👩‍💻 Dashboard Scalingo

Important

N'oubliez pas de déployer l'API pour pouvoir accéder aux fronts et/ou à l’API MaDDo.