{"id":54188,"date":"2019-12-20T00:00:00","date_gmt":"2019-12-19T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/chem-testmace-luchshe-postman"},"modified":"2020-02-18T14:02:10","modified_gmt":"2020-02-18T11:02:10","slug":"chem-testmace-luchshe-postman","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/chem-testmace-luchshe-postman","title":{"rendered":"Pourquoi TestMace est meilleur que Postman.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Pourquoi<\/p>\n

<\/p>\n

Bonjour \u00e0 tous, ici TestMace<\/a><\/noindex>! Il est possible que beaucoup d'entre vous nous connaissent gr\u00e2ce \u00e0 nos<\/a><\/noindex> pr\u00e9c\u00e9dentes<\/a><\/noindex> articles<\/a><\/noindex>. Pour ceux qui viennent de se connecter : nous d\u00e9veloppons un IDE pour travailler avec l'API TestMace. La question la plus fr\u00e9quemment pos\u00e9e lors de la comparaison de TestMace avec des produits concurrents est : \u00ab En quoi vous diff\u00e9renciez-vous de Postman ? \u00bb. Nous avons d\u00e9cid\u00e9 qu'il \u00e9tait temps de fournir une r\u00e9ponse d\u00e9taill\u00e9e \u00e0 cette question. Ci-dessous, nous avons \u00e9num\u00e9r\u00e9 nos avantages par rapport \u00e0 Postman<\/a><\/noindex>.<\/p>\n

<\/a><\/noindex><\/p>\n

Division en n\u0153uds<\/h2>\n

<\/p>\n

Si vous travaillez avec Postman, vous savez que l'interface de requ\u00eate contient toutes les fonctionnalit\u00e9s n\u00e9cessaires. Il y a des scripts, des tests et, en fait, les requ\u00eates elles-m\u00eames. Cela simplifie le travail pour les d\u00e9butants, mais dans de grands sc\u00e9narios, cette approche manque de flexibilit\u00e9. Que se passe-t-il si vous souhaitez cr\u00e9er plusieurs requ\u00eates et en faire l'agr\u00e9gation ? Que faire si vous voulez ex\u00e9cuter un script sans requ\u00eate ou plusieurs scripts logiquement s\u00e9par\u00e9s cons\u00e9cutivement ? Enfin, il serait bien de s\u00e9parer les tests des scripts utilitaires ordinaires. De plus, l'approche \u00ab ajoutons toutes les fonctionnalit\u00e9s dans un seul n\u0153ud \u00bb n'est pas \u00e9volutive - l'interface devient rapidement encombr\u00e9e.<\/p>\n

<\/p>\n

TestMace divise initialement toutes les fonctionnalit\u00e9s en diff\u00e9rents types de n\u0153uds. Vous voulez faire une requ\u00eate ? Voici un n\u0153ud de requ\u00eate.<\/a><\/noindex> Vous voulez \u00e9crire un script ? Voici un script<\/a><\/noindex> n\u0153ud. Besoin de tests ? Pas de probl\u00e8me - Assertion<\/a><\/noindex> n\u0153ud. Ah oui, vous pouvez \u00e9galement envelopper tout cela dans un dossier<\/a><\/noindex> n\u0153ud. Et tout cela s'assemble facilement ensemble. Cette approche est non seulement tr\u00e8s flexible, mais \u00e9galement conforme au principe de responsabilit\u00e9 unique, permettant d'utiliser seulement ce dont vous avez vraiment besoin \u00e0 l'instant. Pourquoi ai-je besoin de scripts et de tests si je veux simplement faire une requ\u00eate ?<\/p>\n

<\/p>\n

Format lisible par l'homme pour le projet<\/h2>\n

<\/p>\n

Il existe une diff\u00e9rence conceptuelle entre TestMace et Postman en ce qui concerne le stockage. Dans Postman, toutes les requ\u00eates sont stock\u00e9es quelque part dans le stockage local. Si vous devez partager des requ\u00eates entre plusieurs utilisateurs, vous devez utiliser la synchronisation int\u00e9gr\u00e9e. En r\u00e9alit\u00e9, c'est une approche standard, mais elle n'est pas sans d\u00e9fauts. Qu'en est-il de la s\u00e9curit\u00e9 des donn\u00e9es ? En effet, la politique de certaines entreprises peut interdire le stockage de donn\u00e9es aupr\u00e8s de tiers. Cependant, nous pensons que TestMace peut offrir quelque chose de mieux ! Et ce mieux s'appelle : \u00ab format projet lisible par l'homme \u00bb.<\/p>\n

<\/p>\n

Commen\u00e7ons par le fait qu'il existe en principe une entit\u00e9 \"projet\" dans TestMace. L'application a \u00e9t\u00e9 initialement con\u00e7ue pour stocker des projets dans des syst\u00e8mes de contr\u00f4le de version : l'arborescence du projet est pratiquement projet\u00e9e un \u00e0 un sur la structure de fichiers, le format de stockage utilis\u00e9 est le yaml (sans crochets ni virgules superflus), et la repr\u00e9sentation des fichiers de chaque n\u0153ud est d\u00e9taill\u00e9e dans la documentation avec des commentaires. Mais dans la plupart des cas, vous ne serez pas amen\u00e9 \u00e0 y jeter un \u0153il \u2014 tous les noms de champs ont des d\u00e9signations logiques. <\/p>\n

<\/p>\n

Que cela apporte-t-il \u00e0 l'utilisateur ? Cela permet de modifier tr\u00e8s flexiblement le flux de travail de l'\u00e9quipe, en utilisant des approches famili\u00e8res. Par exemple, les d\u00e9veloppeurs peuvent stocker le projet dans le m\u00eame r\u00e9f\u00e9rentiel que le backend. Dans les branches, en plus de modifier directement la base de code, le d\u00e9veloppeur peut corriger les sc\u00e9narios de requ\u00eates existants et les tests. Apr\u00e8s avoir valid\u00e9 les modifications dans le r\u00e9f\u00e9rentiel (git, svn, mercurial \u2014 ce que vous pr\u00e9f\u00e9rez), CI (votre outil pr\u00e9f\u00e9r\u00e9, non impos\u00e9 par personne) lance notre utilitaire en ligne de commande testmace-cli<\/a><\/noindex>, et le rapport g\u00e9n\u00e9r\u00e9 apr\u00e8s ex\u00e9cution (par exemple, au format junit, qui est \u00e9galement pris en charge par testmace-cli) est envoy\u00e9 au syst\u00e8me correspondant. De plus, la question mentionn\u00e9e ci-dessus concernant la s\u00e9curit\u00e9 n'est plus un probl\u00e8me.<\/p>\n

<\/p>\n

Comme vous pouvez le voir, TestMace n'impose pas son \u00e9cosyst\u00e8me et sa paradigme. Au lieu de cela, il s'int\u00e8gre facilement dans des processus d\u00e9j\u00e0 \u00e9tablis.<\/p>\n

<\/p>\n

Variables dynamiques<\/h2>\n

<\/p>\n

TestMace suit le concept no-code : si un probl\u00e8me peut \u00eatre r\u00e9solu sans utiliser de code, nous essayons de donner cette possibilit\u00e9. Travailler avec des variables est exactement cette fonctionnalit\u00e9 o\u00f9, dans la plupart des cas, on peut se passer de programmation.<\/p>\n

<\/p>\n

Exemple : nous avons re\u00e7u une r\u00e9ponse du serveur, et nous souhaitons sauvegarder une partie de la r\u00e9ponse dans une variable. Dans Postman, nous aurions \u00e9crit dans le script de test (ce qui est en soi \u00e9trange) quelque chose comme :<\/p>\n

<\/p>\n

var jsonData = JSON.parse(responseBody);\npostman.setEnvironmentVariable(\"data\", jsonData.data);<\/code><\/pre>\n
<\/p>\n
Mais \u00e0 notre avis, \u00e9crire un script pour un sc\u00e9nario aussi simple et souvent utilis\u00e9 semble excessif. C'est pourquoi dans TestMace, il est possible d'assigner une partie de la r\u00e9ponse \u00e0 une variable en utilisant l'interface graphique. Regardez comme c'est simple :<\/p>\n
<\/p>\n
\"Pourquoi<\/p>\n
<\/p>\n
Et maintenant, \u00e0 chaque requ\u00eate, cette variable dynamique sera mise \u00e0 jour. Mais vous pourriez contester cela en argumentant que l'approche de Postman est plus flexible et permet non seulement de faire une affectation, mais \u00e9galement d'ex\u00e9cuter un certain pr\u00e9traitement. Voici comment modifier l'exemple pr\u00e9c\u00e9dent :<\/p>\n
<\/p>\n
var jsonData = JSON.parse(responseBody);\npostman.setEnvironmentVariable(\"data\", CryptoJS.MD5(jsonData.data));<\/code><\/pre>\n
<\/p>\n
Eh bien, pour cela, TestMace dispose d script<\/a><\/noindex> un n\u0153ud qui couvre ce sc\u00e9nario. Pour reproduire le cas pr\u00e9c\u00e9dent, mais d\u00e9j\u00e0 dans l'ex\u00e9cution de TestMace, il est n\u00e9cessaire de cr\u00e9er un n\u0153ud script apr\u00e8s la requ\u00eate et d'utiliser le code suivant comme script :<\/p>\n
<\/p>\n
const data = tm.currentNode.prev.response.body.data;\ntm.currentNode.parent.setDynamicVar('data', crypto.MD5(data));<\/code><\/pre>\n
<\/p>\n
Comme vous pouvez le voir, la composition des n\u0153uds a encore \u00e9t\u00e9 utile ici. Et pour un cas aussi simple que celui d\u00e9crit ci-dessus, vous pouvez m\u00eame simplement affecter l'expression ${crypto.MD5($response.data)}<\/code> \u00e0 une variable cr\u00e9\u00e9e via l'interface graphique !<\/p>\n
<\/p>\n
Cr\u00e9ation de tests via l'IU<\/h2>\n
<\/p>\n
Postman permet de cr\u00e9er des tests en \u00e9crivant des scripts (dans le cas de Postman, c'est du JavaScript). Cette approche pr\u00e9sente de nombreux avantages : flexibilit\u00e9 presque illimit\u00e9e, disponibilit\u00e9 de solutions pr\u00eates \u00e0 l'emploi, etc.<\/p>\n
<\/p>\n
Cependant, la r\u00e9alit\u00e9 est souvent telle (ce n'est pas nous, c'est la vie) que le testeur n'a pas de comp\u00e9tences en programmation, et l'\u00e9quipe aimerait apporter de la valeur imm\u00e9diatement. Pour de tels cas, dans le cadre du concept no-code, TestMace permet de cr\u00e9er des tests simples via l'interface graphique, sans avoir besoin d'\u00e9crire des scripts. Voici, par exemple, \u00e0 quoi ressemble le processus de cr\u00e9ation d'un test qui compare des valeurs pour l'\u00e9galit\u00e9 :<\/p>\n
<\/p>\n
\"Pourquoi<\/p>\n
<\/p>\n
Cependant, la cr\u00e9ation de tests dans l'\u00e9diteur graphique n'annule pas la possibilit\u00e9 d'\u00e9crire des tests en code<\/a><\/noindex>. Ici, toutes les m\u00eames biblioth\u00e8ques que dans le n\u0153ud script, et chai<\/a><\/noindex> pour \u00e9crire des tests.<\/p>\n
<\/p>\n
Autres diff\u00e9rences<\/h2>\n
<\/p>\n