KivTools

Préparer des tests depuis une opération OpenAPI

Choisissez l’opération et le format de sortie. Ajoutez authentification, jeux de données et assertions de contrat ; les tests ne sont pas exécutés sur cette page.

Fonctionne localement dans votre navigateur
Voir la catégorie: Développement d’API (15)
Tout dans cet outil est traité dans ce navigateur. KivTools ne télécharge pas, ne stocke pas et n’appelle aucune API tierce avec votre entrée.
Définition OpenAPICollez un document OpenAPI 3.x ou Swagger 2.0 en JSON/YAML. Il est analysé localement ; aucun serveur ni point de terminaison n’est contacté.
Cas de tests générés

Comment préparer des cas de test depuis une opération OpenAPI

Collez un document OpenAPI 3.x ou Swagger 2.0, ou ouvrez un fichier local .json, .yaml ou .yml. Les chemins, paramètres, corps de requête et réponses sont lus dans le navigateur, et les opérations trouvées sont listées pour que vous en choisissiez une.

Choisissez une opération, puis Plan de test JSON pour voir les cas à couvrir ou Vitest + fetch pour obtenir une base exécutable qui construit la requête. Rien n’est envoyé et aucun endpoint n’est appelé.

  1. Collez la définition ou chargez un fichier, puis cliquez sur Analyser API. Chaque opération sous paths apparaît avec sa méthode, son chemin et son résumé.
  2. Sélectionnez l’opération, choisissez Plan de test JSON ou Vitest + fetch, puis cliquez sur Générer des tests. Le résultat s’affiche dans le cadre du bas.
  3. Utilisez Copier ou Télécharger pour emporter le résultat ; Effacer vide l’entrée, la liste des opérations et la sortie.
  4. Avant d’exécuter quoi que ce soit, ajoutez ce que vous seul savez : authentification, données de test réelles, l’URL de base si le document n’a pas de serveur et les assertions exigées par votre contrat.

Ce que couvrent le plan et la base, et ce qui vous reste

Ce que la lecture du document couvre

Les références locales sont résolues jusqu’à leur définition : paramètres déclarés sur un chemin, corps de requête et schémas de components. Les paramètres de chemin sont toujours traités comme obligatoires, comme l’exige la spécification, même si le document oublie la marque.

Les documents Swagger 2.0 sont lus aussi. L’URL de base est composée à partir de schemes, host et basePath, et un paramètre body devient le corps JSON. En OpenAPI 3, la première URL de servers est utilisée, les variables de serveur étant remplacées par leur valeur par défaut.

Ce que contient le code généré

Le fichier Vitest importe describe, expect et it ; déclare chaque paramètre de chemin en constante camelCase ; construit l’URL avec encodeURIComponent ; définit les paramètres de requête via URLSearchParams ; et envoie le corps JSON avec l’en-tête Content-Type correspondant. Sa seule assertion est un statut 2xx.

Le plan JSON contient un chemin nominal, un cas d’entrée manquante par paramètre obligatoire (paramètres de chemin et corps compris) et un cas par réponse 4xx ou 5xx documentée. Les deux formats lisent le document de la même façon : les noms de cas correspondent à la base.

Où l’outil s’arrête

Tout s’exécute dans la page et les tests générés ne sont pas lancés ici. Un statut 2xx ne prouve pas que le corps de la réponse respecte son schéma : considérez la sortie comme un brouillon à compléter.

Les documents très volumineux sont analysés dans le navigateur eux aussi ; si l’un devient lent, réduisez-le aux chemins testés. Pour vérifier d’abord la définition elle-même, le validateur OpenAPI de la même catégorie signale les problèmes de structure et de références.

Outils récents :