Produits Entr'ouvert » w.c.s.

Très rébarbatif comme dev, un plan alternatif germe dans ma tête.

Notons d'abord qu'un autre truc important qu'il manque pour que les tests soient complets c'est l'action création/modification d'un fiche/demande.

On imagine que tester la création ce serait avoir une action de test « Vérifier qu'une fiche a été créée », en sélectionnant un modèle de fiche puis en indiquant des couples (identifiant d'un champ, valeur attendue).

Première idée d'implémentation, intercepter la création de la fiche, pour ne pas la créer vraiment mais avoir quand même l'objet CardData et vérifier la valeur des champs. Mais il faut tout de même que dans la suite du test on puisse accéder à la fiche créée via form_links_xxx ou cards|objects, ce qui rajoute un niveau de mocks potentiellement pénibles.

Deuxième idée d'implémentation, on laisse la fiche être réellement créée, mais le test tourne dans une transaction, qu'on rollback une fois l'exécution terminée. Ça devrait éviter les mocks. Reste l'inspecteur du résultat du test, où il faut pouvoir visualiser et manipuler le fiche créée via form_links_xxx ou cards|objects. Donc avant de rollback la transaction il faut stocker la fiche dans le JSON du résultat, et la restaurer avec les liens au moment de consulter l'inspect.

Troisième idée, on laisse la fiche être réellement créée en persistant après la fin du test, ça enlève ce besoin d'inventer un stockage/restauration. Du même coup on laisse la demande issue du test être créée aussi, ça enlève du code déjà écrit qui stocke/restaure en JSON (et qui engendre du travail, dernier en date #93759). Pour que ces objets issus des tests ne soient pas mélangés, on les enregistre avec un flag test_result_id=42, qui les masque partout ailleurs que dans le résultat du test qui a pour identifiant 42 : c'est là que ça commence à ressembler à l'objet du présent ticket.

Parce que si on en arrive là, on peut facilement dire que l'exécution d'un test dépend d'un autre.

Concrètement, si on imagine une démarche d'inscription à la piscine sur l'année 2024, puis une démarche réservation d'un créneau, à laquelle l'usager ne peut accéder que s'il est déjà connu via une fiche inscription, via une condition utilisant |filter_by_user.

Pour tester cette deuxième démarche avec l'approche suggérée dans la description du ticket, il faut aller manuellement créer une fiche de test « inscription à la piscine pour l'usager XXX », puis créer un test en demandant à ce que cette fiche soit accessible depuis le test.

Avec l'idée de la dépendance entre les tests, il suffit de créer le test sur la réservation en déclarant une dépendance à un test de la démarche inscription.

C'est fonctionnellement assez différent, difficile de lister précisément ce qui sera plus pratique dans un cas et moins dans l'autre. Un avantage tout de même à cette deuxième idée me semble être qu'une évolution de la fiche inscription est automatiquement répercutée dans le test de la réservation. Avec l'idée d'une fiche statique, on peut se retrouver à tester un cas qui n'existe plus réellement, et pour éviter cela il faut penser à aller mettre à jour les champs de la fiche manuellement.

En tout cas niveau dev ça paraît nettement plus confortable, notamment car c'est découpable en petits tickets indépendants, vs ici où il y a beaucoup trop à inventer à la fois :

• Stockage en base de la demande issue d'un test, retrait du code qui stocke/restaure en JSON
• Ajout d'une action de test pour vérifier la création d'une fiche/demande
• Ajout de la dépendance entre les tests