Produits Entr'ouvert » Passerelle

C'est cool mais serait mieux un peux mieux si tu choisissais 'room', 'theme' et 'event' au hasard en se basant sur des appels aux endpoints correspondants.

Ça correspond plus à ce que ferait un forkflow, et permet de vérifier que ce que te renvoie les endpoints est bien formaté comme il faut pour être utilisable pour poser une réservation ...

De mon coté je voyais plus les functests comme des tests pytest classiques mais nécessitant une instance de vivaticket en vrai, pas une instance de passerelle en vrai (pour ça pytest-django fournit déjà de quoi), genre donc avec une fixture vivaticket qui utilise le paramètre --vivaticket-url pour créer la ressource puis taper dessus (peut-être même pas via les web-services mais via l'objet ressource directement).

Benjamin Dauvergne a écrit :

De mon coté je voyais plus les functests comme des tests pytest classiques mais nécessitant une instance de vivaticket en vrai, pas une instance de passerelle en vrai (pour ça pytest-django fournit déjà de quoi), genre donc avec une fixture vivaticket qui utilise le paramètre --vivaticket-url pour créer la ressource puis taper dessus (peut-être même pas via les web-services mais via l'objet ressource directement).

C'est pas ce que j'ai fait dans cmis et planitech où j'ai bien une vrai instance du connecteur. Ton approche me parait valable aussi (avec une préférence pour taper dans les webservices et pas juste sur l'instance).

Dans les deux cas on gagne quand même quelque chose d'important, avec une vrai instance du logiciel métier qui répond, laissons le choix de la méthode à celui qui écrit le patch non ?

Emmanuel Cazenave a écrit :

Benjamin Dauvergne a écrit :

De mon coté je voyais plus les functests comme des tests pytest classiques mais nécessitant une instance de vivaticket en vrai, pas une instance de passerelle en vrai (pour ça pytest-django fournit déjà de quoi), genre donc avec une fixture vivaticket qui utilise le paramètre --vivaticket-url pour créer la ressource puis taper dessus (peut-être même pas via les web-services mais via l'objet ressource directement).

C'est pas ce que j'ai fait dans cmis et planitech où j'ai bien une vrai instance du connecteur. Ton approche me parait valable aussi (avec une préférence pour taper dans les webservices et pas juste sur l'instance).

Dans les deux cas on gagne quand même quelque chose d'important, avec une vrai instance du logiciel métier qui répond, laissons le choix de la méthode à celui qui écrit le patch non ?

Si tu parles des deux cas: en passant par les web-service ou directement via l'objet ressource, sûr, je n'ai pas de préférence. Mais nécessiter de configurer d'abord une instance de passerelle à mon avis ça limitera drastiquement les cas où quelqu'un reviendra les lancer, ou bien on prévoit aussi les deux donnant la possibilité de venir tester une instance déployé (genre en recette) ou directement depuis sa machine.

Les deux cas, je parlais ton approche/la mienne, pas d'instance de connecteur/une vrai instance de connecteur.

'Limite drastique' n'exagérons rien, un connecteur ça prend 1 minutes à se créer, ça se garde sous le coude sans problème (en bonus on est souvent content d'aller voir les logs dans l'UI pour comprendre ce qui a merdé quand ça merde). Bref ce point ne me parait pas crucial.

Avoir les tests via pytest, c'est pouvoir les faire tourner depuis jenkins, avec l'espoir d'être ainsi notifiés sur des changements d'API/comportement, plutôt qu'arriver des jours/semaines/mois plus tard à ce qu'on nous signale un problème, qu'on fasse tourner les tests, qu'on dise qu'ah oui, en effet, quelque chose a changé, mais qu'on ne puisse pas être plus précis que ça. (alors que pouvoir pointer du doigt l'application, au moment où elle fait un changement incompatible, met la responsabilité de son côté).

(on peut en discuter à un autre moment et ailleurs, et se dire que mieux que rien, c'est déjà beaucoup, je ne veux pas bloquer ce ticket).

Je suis d'accord avec l'idée de Frédéric. A faire juste attention que certaines plateformes de webservice peuvent imposer une restriction d'accès par IP, et il faudrait pas que ces tests cassent les tests unitaires et les builds des paquets.

A discuter ailleurs certainement.