Journal Reqman(2), un postman GPL qui utilise de simples fichiers YAML

Posté par (page perso) . Licence CC by-sa.
Tags : aucun
23
12
déc.
2019

Une vidéo d’une minute.

Reqman est un outil en ligne de commande qui permet de tester ses API Web… tout comme postman, mais les requêtes et tests sont décrits dans de simples fichiers YAML.

Écrire des tests est extrêmement simple (pas besoin de JS, comme postman), et n’importe qui devrait être en mesure d’en écrire (avec un peu de doc quand même ;-)).

Dispo sur PyPI et sur GitHub, tout comme sa documentation.

Démo : une version en ligne qui permet de jouer des tests (avec quelques limites ;-) pour se faire une idée.

Bonus : un outil en ligne pour convertir un fichier swagger/openapi3, une collection postman, ou une archive HAR en tests reqman. Histoire de démarrer plus facilement.

Ça fait la même chose que postman (et un peu plus), c’est GPL, ça utilise les mêmes concepts de collections (juste un répertoire, et des fichiers de tests), et d’environnements (avec un fichier de conf). Les tests sont d’office partageables dans un gestionnaire de sources pour travailler à plusieurs (contrairement à une collection postman qui n’est qu’un seul fichier JSON). C’est facilement scriptable (crontab & co) pour automatiser tout ça. Et les fichiers de tests sont éditables dans n’importe quel éditeur qui supporte le YAML (y compris vi/emacs en SSH)

Je l’utilise tous les jours… et suis persuadé que ça peut aider d’autres personnes.

  • # Les cookies

    Posté par . Évalué à 4 (+2/-0).

    Très intéressant, postman me prend trop de RAM juste pour tester mes endpoints, c'est désagréable.

    Y'a bien "cookie handling" dans le README, mais je ne trouve aucune mention sans la doc https://reqman-docs.glitch.me/ Donc ils sont gérés comment, stockés où, je peux explorer le contenu, les supprimer, … ?

    • [^] # Re: Les cookies

      Posté par (page perso) . Évalué à 1 (+0/-0).

      Les cookies créés lors d'une requête sont conservés et transmis dans les requêtes suivantes (dans la mesure où on reste sur le même domaine, path, etc…) … bref, tout comme une classique session http. (c'est ce que j'appel le "cookie handling"). (Techniqement, ils sont stockées dans la mémoire, lors de la session de test)
      Il n'y a pas (encore) de méthodes spécifiques autour des cookies (je n'en ai jamais vraiment ressenti le besoin). Ces derniers circulent par les headers http in/out. Du coup, le cookie est écrasable (via le header set-cookie, pour ne pas le re-transférer) … et récupérable dans les tests (pour tester).
      C'est minimaliste, certes … maintenant, est-ce suffisant ?! … mais effectivement il manquerait peut être qques sucres syntaxiques pour rendre cela plus facile, sans trop complexifier…

  • # don't be evil he said...

    Posté par . Évalué à 4 (+2/-0).

    https://reqman-tools.glitch.me/
    NOTE: Nothing is saved on server side, believe me !
    (3251 conversions)

    Je sais pas pourquoi, mais il y a quelque chose qui me chipote…

  • # Sympa

    Posté par (page perso) . Évalué à 2 (+1/-0).

    J'aime bien. Allez hop, c'est adopté !

    • [^] # Re: Sympa

      Posté par (page perso) . Évalué à 1 (+0/-0).

      cool …

      n'hésite pas à faire du feedback …
      mon equipe et moi même l'utilisons tous les jours (plusieurs fois par jour !). ça réponds carrément à nos besoins, et j'aimerai savoir si ça réponds aux besoins des autres … sachant que j'ai tout fait pour que ça le fasse … (en me basant sur les concepts postman .. de collections (mais avec des folders/fichiers) et sur les environnements (avec le fichier reqman.conf))

      Nous, on a plus de 2000 tests, avec 500 requests … sur environs 100 apis rests, à travers plusieurs ressources, avec oauth2 flow … qu'on peut jouer et comparer sur 4 environnements différents (du local à la prod). J'ai également 500 tests sur diverses api persos …
      ça marche bien … pour nous/moi.

  • # « de simples fichiers YAML »

    Posté par . Évalué à 1 (+4/-4).

    Quand on sait l’enfer que c’est de travailler avec ce format…

    • [^] # Re: « de simples fichiers YAML »

      Posté par . Évalué à 1 (+1/-2).

      Tu peux préciser STP ? Ça m'intéresserait d'avoir des exemples.

    • [^] # Re: « de simples fichiers YAML »

      Posté par . Évalué à 2 (+3/-3).

      Oui et non.

      C'est un format très lisible et très intuitif à utiliser pour un humain, comparables aux bons vieux .ini.

      Après c'est plus au niveau du parsing que ça peut être une plaie comparé par exemple à du json ou du xml mais à moins que tu ne sois toi-même dev d'une lib de parsing ce n'est plus vraiment ton problème.

      • [^] # Re: « de simples fichiers YAML »

        Posté par . Évalué à 6 (+5/-0).

        L'indentation, le typage, les différentes façon de construire une string sur plusieurs lignes (qui sont équivalente ou pas),… sont quelques exemples de cas pas hyper agréable à utiliser.

        C'est un format formidable pour son expressivité, mais c'est pas le plus agréable à utiliser.

        • [^] # Re: « de simples fichiers YAML »

          Posté par (page perso) . Évalué à -2 (+0/-3).

          pas le plus agréable à utiliser.

          Avec un bon editeur, avec coloration syntaxique et tutti canti … ça va, au moins pour débuter.
          EN venant du monde python c'est peut être plus naturel d'avoir son éditeur réglé avec l'indentation sur 4 espaces. (pour éviter le mix tab/spaces)

          Après, quand tu as compris … ça va tout seul.

          • [^] # Re: « de simples fichiers YAML »

            Posté par . Évalué à 3 (+2/-0).

            J'ai eu quelques pièges avec des variables vides, du genre :

            foo:
                bar:

            Impossible de savoir ce qu'est ce bar. Je peux expliciter une séquence vide avec :

            foo:
                bar: []

            Mais ça n'est pas hyper pratique, il faut que je passe d'une forme à l'autre selon mes besoins.

            Et puis bon le die and retry, même dans les jeux vidéos, je n'en suis pas fan.

            Après, quand tu as compris … ça va tout seul.

            Je ne suis jamais tout à fait sûr de moi pour les séquences.

            Encore une fois ce n'est pas bloquant et le format a d'autres avantages géniaux, mais il n'est pas parfait pour autant.

    • [^] # Re: « de simples fichiers YAML »

      Posté par (page perso) . Évalué à 0 (+2/-3).

      C'est vendredi … et je me retiens … (pas de trolls .. pas de trolls)

      C'est marrant comme les consciences ont évolué … mais qu'est ce que ça prends du temps !!!

      Il y a 20ans, on disait la même chose du python … patati, patata l'indentation …
      Maintenant, c'est complètement acquis …

      Il y a 10ans, le yaml rencontrait les mêmes rancœurs que le python jadis … patati patata l'indentation …
      Et maintenant, en faisant un peu gaffe; on voit que le yaml est vraiment devenu presque le standard au niveau config un peu partout.

      Du coup, on peut penser que dans 10ans … il sera complètement accepté !
      Bref … c'est une good news !

      • [^] # Re: « de simples fichiers YAML »

        Posté par . Évalué à 4 (+3/-0). Dernière modification le 13/12/19 à 19:39.

        Ah ben c’est sûr, on fini toujours par s’adapter à tout. Ça veut pas dire qu’on est d’accord pour autant.

        • [^] # Re: « de simples fichiers YAML »

          Posté par . Évalué à 4 (+3/-1).

          je suis d'accord avec toi. Python a beaucoup d'avantages, mais je trouve cette obligation d'indentation plus problématique qu'autre chose. La raison invoquée, "produire du code propre", ne me paraît pas suffisante, en effet du code "propre", mais pas commenté, ne sert à rien, donc c'est au développeur de gérer la manière dont c'est écrit et indenté.

          En revanche, lorsqu'on recopie des exemples en python depuis une page web, souvent le code est tout cassé à cause des indentations. Et puis de toute façon, des espaces non visibles comme délimiteur de code, ça me dérange intellectuellement, à un moment où un autre, on se retrouve emmerdé (ça peut être devoir modifier du code python sur un serveur via ssh, avec l'éditeur par défaut par exemple).

      • [^] # Re: « de simples fichiers YAML »

        Posté par (page perso) . Évalué à 10 (+9/-0).

        Je pense que la grande différence est le contexte: quand je travaille sur un code python, j'utilise généralement un IDE, car je sais qu'il y a beaucoup de conventions à respecter. J'espère que tout le monde se rend compte que modifier un code, n'est pas du tout un acte anodin et qu'il y a beaucoup de règles à respecter.

        Les tabulations / espaces, c'est un des premiers trucs que l'on apprend en lisant des tutos sur python.

        Par contre, quand je modifie un fichier de configuration, ça doit être un acte anodin. Il doit être possible de le faire sans IDE (emacs, vim ne sont pas toujours installés sur tous les postes/serveurs).

        Un exemple typique, est que je vois un comportement par défaut que je veux changer. J'ouvre le fichier de configuration, je voit que c'est du texte et je l'adaptes selon le reste du fichier. Je le fais avec un simple éditeur de texte (qui ouvrirait un fichier de config avec un IDE ?) et je ne vois pas la différence entre espace/tabulation. Maintenant, avec un fichier .ini tout se passe sans problèmes, avec un fichier .yml, il y a 9 chances sur 10 que je vienne de casser mon service/programme.

        Je pense que le contexte fait vraiment la différence pour l'édition: pour un code, les gens savent qu'il faut suivre une formation, mais pour une configuration, des administrateurs systèmes, des utilisateurs doivent pouvoir les modifier.

        Maintenant, dans le cas de reqman, je comprends l'utilisation de yaml: c'est un outil destiné à des développeurs / testeurs, ça ne me choque pas :)

        • [^] # Re: « de simples fichiers YAML »

          Posté par . Évalué à -8 (+0/-10).

          Par contre, quand je modifie un fichier de configuration, ça doit être un acte anodin. Il doit être possible de le faire sans IDE (emacs, vim ne sont pas toujours installés sur tous les postes/serveurs).

          D'une part si tu édites encore des fichiers de conf directement sur les serveurs en 2019 c'est que t'as déjà tout faux et pas ta place dans l'industrie, d'autre part tu n'as pas besoin d'utiliser l'éditeur présent sur le serveur pour y éditer un fichier (hello points de montages ssh) et pour finir avoir de la coloration syntaxique et du linting n'est qu'à un jet de pierre pip/gem/yum/dnf/gem.

          Du coup ce n'est pas un argument vraiment pertinent.

          • [^] # Re: « de simples fichiers YAML »

            Posté par (page perso) . Évalué à 6 (+4/-0).

            D'une part si tu édites encore des fichiers de conf directement sur les serveurs en 2019 c'est que t'as déjà tout faux et pas ta place dans l'industrie

            Merci pour ce chaleureux message, j'avais peur de ne pas savoir où est ma place…

            Je peux te rassurer: je ne suis pas administrateur système en industrie :-)

            d'autre part tu n'as pas besoin d'utiliser l'éditeur présent sur le serveur pour y éditer un fichier (hello points de montages ssh)

            Ok, c'est quand même un échec pour un fichier de configuration : pour pouvoir bien l'éditer, tu dois sortir une autre machine.

            pour finir avoir de la coloration syntaxique et du linting n'est qu'à un jet de pierre pip/gem/yum/dnf/gem.

            Le problème pour un utilisateur normal, c'est qu'il va casser sa configuration puis se rendre compte après qu'il a besoin d'un linter.

            Pour du code, ça ne me pose pas de problème, mais pour un simple ajustement de configuration, c'est hyper lourd.

            • [^] # Re: « de simples fichiers YAML »

              Posté par . Évalué à 3 (+2/-0). Dernière modification le 14/12/19 à 20:06.

              Et quand bien même, dans mon boulot je manipule de temps à autres des fichiers de configuration Kubernetes. Ils sont en YAML, et en aucun cas « directement sur les serveurs ».

              À mon sens tes arguments sont valides et tu n’aurais pas de problème pour « bosser dans l’industrie ». On a du YAML partout, sauf sur les serveurs \o/

              En plus de cela « hello point de montage » ça revient à éditer un fichier de conf « sur le serveur ». C’est tout autant éloigné des pratiques "modernes".

      • [^] # Re: « de simples fichiers YAML »

        Posté par (page perso) . Évalué à 8 (+9/-4).

        Il y a 20ans, on disait la même chose du python … patati, patata l'indentation …
        Maintenant, c'est complètement acquis …

        Oui c'est complètement acquis: tout le monde est d'accord pour dire que l'indentation dans Python est une erreur.

        Incubez l'excellence sur https://linuxfr.org/board/

        • [^] # Re: « de simples fichiers YAML »

          Posté par (page perso) . Évalué à 2 (+0/-0). Dernière modification le 18/12/19 à 19:47.

          C'est pour cela qu'ont été ajoutés les mots clés #begin et #end (à mettre seuls sur leur ligne en début et fin de bloc, en respectant l'indentation tout de même).

          Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

        • [^] # Re: « de simples fichiers YAML »

          Posté par (page perso) . Évalué à 1 (+0/-0).

          C’est vite dit. Je suis en tout cas une exception.

          La syntaxe Python est très expressive et concise. Tu mets un peu de EditorConfig dans ton projet et ça roule.

  • # Coquille dans la doc

    Posté par (page perso) . Évalué à 2 (+1/-0).

    Il y a une coquille dans la doc : dans From Postman: "If you came from postamn" (postamn -> postman). Je n'ai pas trouvé le dépôt contenant la doc sinon j'aurais fait une pull request avec le fix.

    Sinon l'icône en haut à gauche du site de doc pointe sur http://127.0.0.1:8000/.

    Je m'en vais de ce pas tester l'outil, merci.

    WeeChat, the extensible chat client

  • # testmace : des avis ?

    Posté par . Évalué à 1 (+0/-0).

    Quelqu'un a-t-il déjà utilisé ? :
    https://testmace.com/

    Merci

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.