Produits Entr'ouvert » w.c.s.

Ce serait bien de faire un récap sur ce qu'à apporter #95255 (donc le passage si je comprends d'une sérialisation en JSON des formdata? carddata? dans l'objet qui stocke l'exécution du test vers un stockage dans les tables normales stockant les demande, ne pas hésiter à modifier ma prose si ce n'est pas une bonne decription du changement) pour voir d'où on vient et où on va.

• tout stocker dans une autre table (mais donc si le changement #95255 visait à éviter trop de changement partout ben ce sera raté)
• faire tourner les tests dans une transaction, qu'on rollback avant sa fin, comme pytest-django avec l'ORM django (mais ça n'enlèvera pas l'incrémentation des séquences qui n'est pas protégée par les transactions)

Benjamin Dauvergne a écrit :

Ce serait bien de faire un récap sur ce qu'à apporter #95255 (donc le passage si je comprends d'une sérialisation en JSON des formdata? carddata? dans l'objet qui stocke l'exécution du test vers un stockage dans les tables normales stockant les demande, ne pas hésiter à modifier ma prose si ce n'est pas une bonne decription du changement) pour voir d'où on vient et où on va.

• Simplification du code, plus besoin de serialiser et surtout deserialiser (le code a pas encore été retiré pour maintenir une compatibilité mais il faudrait (d'ailleurs la deserialisation était incomplète, on a rien pour transformer le JSON des evolutions en objets evolution))
• Possibilité de tester la création d'une demande simplement, avec un inspect du résultat qui fonctionne (https://git.entrouvert.org/entrouvert/wcs/commit/9f8e7db82ff8cb3505d30e2defc644e9825bb8ef)
• Pareil pour la dépendance entre les tests, ça aurait été je pense nettement plus compliqué avec de faux objets

J'ai un peu philosophé sur le sujet ici #92388-2.

Je propose deux autres pistes:

• tout stocker dans une autre table (mais donc si le changement #95255 visait à éviter trop de changement partout ben ce sera raté)

Je ne comprends pas cette piste mais oui plus le chemin des tests divergera du chemin réel moins tout ça marchera.

• faire tourner les tests dans une transaction, qu'on rollback avant sa fin, comme pytest-django avec l'ORM django (mais ça n'enlèvera pas l'incrémentation des séquences qui n'est pas protégée par les transactions)

Ici on part du principe que l'incrémentation est un problème, sinon on pourrait juste changer les index pour que postgres soit content (c'est ce que je comprends de ce que dit Pierre).

Qu'est-ce qui ne va pas à avoir deux tables par formdata ? Pierre semblait dire que c'était OK.

Valentin Deniaud a écrit :

Qu'est-ce qui ne va pas à avoir deux tables par formdata ? Pierre semblait dire que c'était OK.

Si ça n'est pas nécessaire je ne vois pas de raison de le faire; j'ai l'impression qu'on pourrait s'en sortir simplement en dupliquant le formdata formdef avant de lancer les tests puis en le supprimant. Non ?

Benjamin Dauvergne a écrit :

Si ça n'est pas nécessaire je ne vois pas de raison de le faire; j'ai l'impression qu'on pourrait s'en sortir simplement en dupliquant le formdata avant de lancer les tests puis en le supprimant. Non ?

Non à la fin du test le formdata ne doit pas être supprimé, il doit rester attaché au résultat, ce qui permet ensuite d'accéder à l'inspecteur, nécessaire pour débugger un test planté.

(un exemple pour comprendre comment ça fonctionne en vrai, notre appli congés https://formulaires-www.entrouvert.com/backoffice/forms/32/)

Je voulais dire formdef plus haut pas formdata; m'est avis que doublon de table ou pas il faudra un formdef alternatif de toute façon à un moment donné. J'arrête d'intervenir, on verra sur pièce.

Valentin Deniaud (vdeniaud) a demandé une relecture de Frédéric Péters (fpeters) sur une pull request sur Gitea concernant cette demande :

• URL : https://git.entrouvert.org/entrouvert/wcs/pulls/2033