Ce que JSONPlaceholder vous apporte
Des ressources prévisibles. Posts, commentaires, utilisateurs, todos et albums, avec des identifiants stables et des structures cohérentes.
Tous les verbes. GET, POST, PUT, PATCH et DELETE répondent tous de manière cohérente.
Des relations imbriquées. Les commentaires appartiennent aux posts, les posts aux utilisateurs. Assez de structure pour vous entraîner.
La leçon involontaire
Les écritures sur JSONPlaceholder sont simulées. Vous envoyez un POST, vous recevez un 201 avec un identifiant, et rien n'a été enregistré. Récupérez la ressource : elle n'est pas là.
La plupart des gens y voient une limite. C'est pourtant ce que le service a de plus utile, parce que cela sépare deux idées que les débutants confondent systématiquement : la requête a réussi et le changement a eu lieu. Une suite qui ne vérifie que les codes de statut passera ici tous les tests d'écriture, avec assurance, indéfiniment.
Si votre assertion survit aux fausses écritures de JSONPlaceholder, c'est une assertion faible. Réécrivez-la pour vérifier qu'ensuite la ressource existe réellement, et gardez cette habitude sur votre vraie API, où la même faiblesse est invisible.
À quoi vous entraîner ici, dans l'ordre
Structures et champs
Faites porter vos assertions sur la structure du corps de la réponse plutôt que sur le statut.
Contrôlez les types, pas seulement la présence des champs.
Relations
Récupérez un post, puis ses commentaires, et vérifiez qu'ils y font bien référence.
La plupart des vrais bugs se cachent entre deux appels.
Cas d'erreur
Demandez un identifiant qui n'existe pas et vérifiez que la réponse a la bonne structure.
Le test que tout le monde saute, et celui qui détecte vraiment les problèmes.
Ce qu'elle ne peut pas vous apprendre
Tout ce qui touche à l'état, c'est-à-dire tout ce qui rend le test d'API difficile dans la vraie vie. Les sessions et leur expiration, les valeurs capturées dans une réponse et réutilisées dans la suivante, les appels qui doivent s'enchaîner dans un ordre précis, et le nettoyage après une exécution. JSONPlaceholder n'a rien de tout cela, puisque rien n'y persiste.
C'est donc une excellente première heure, et une deuxième semaine trompeuse. Passez à une API dotée d'un véritable état dès que les bases sont acquises, et attendez-vous à un net saut de difficulté.
Une première heure qui vous servira ailleurs
Pour que cet entraînement vaille quelque chose sur votre propre API, faites ces quatre exercices dans l'ordre plutôt que d'explorer au hasard.
Récupérez un post et vérifiez trois champs précis avec leurs types, pas seulement que l'appel a réussi. Récupérez un post qui n'existe pas et vérifiez le statut ainsi que la structure de ce qui revient. Récupérez un post, puis ses commentaires, et vérifiez que chaque commentaire fait bien référence au post demandé. Créez ensuite un post, récupérez-le, et regardez l'assertion échouer.
Ce dernier exercice est tout l'intérêt de la démarche. L'écriture a signalé un succès, l'identifiant est revenu, et rien n'a persisté. Toutes les habitudes qui valent la peine d'être emportées vers une vraie API tiennent là : comprendre pourquoi votre test est quand même passé, puis le réécrire pour qu'il ne passe plus.
Passer à un vrai service
Ces quatre points, une couche dédiée les prend en charge sous les noms Auto-Authentication, Dynamic Variables, Dependency Chains et Auto-Cleanup. Le fonctionnement est détaillé dans la documentation sur les tests d'API.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Le tableau de bord couvre le même terrain pour qui ne veut pas d'installation locale, et l'ensemble des commandes est décrit dans le dépôt du CLI.
Ce qui change quand vous le pointez vers une vraie API
Tout ce que JSONPlaceholder ne peut pas vous apprendre, c'est précisément ce dont TestSprite s'occupe. Auto-Authentication pour les sessions qui expirent en cours d'exécution. Dynamic Variables pour l'identifiant renvoyé par un appel de création. Dependency Chains pour les appels qui ne peuvent avoir lieu qu'une fois autre chose faite. Auto-Cleanup pour les enregistrements que chaque exécution laisse derrière elle.
Le premier geste est le même que dans l'exercice ci-dessus : faites pointer un projet vers votre URL de base, laissez API Discovery énumérer ce qui existe, et lisez le plan généré avant de lancer quoi que ce soit. La différence, c'est que le plan couvre désormais l'autorisation et les cas limites, face à un service où les écritures sont réellement persistées.
Ce que vous y gagnez est exactement ce vers quoi l'entraînement menait : des assertions qui résistent au contact de l'état, exécutées à chaque changement plutôt que lorsque vous y pensez.
Pourquoi mes requêtes POST ne sont-elles pas persistées ?
C'est voulu. JSONPlaceholder simule les écritures. Prenez-le comme une leçon : faites porter vos assertions sur les résultats, pas sur les réponses.
Est-ce adapté à la CI ?
Pour une suite de tutoriel, ponctuellement. Pour tout ce qui s'exécute à chaque commit, utilisez plutôt un mock local. C'est un service gratuit et partagé.
Vers quoi passer ensuite ?
Vers quelque chose qui a de l'authentification et une vraie persistance. Le saut de difficulté est justement le but, et c'est là que commence la compétence transposable.
Puis-je y brancher un générateur de tests ?
Oui, et c'est un terrain sans risque pour voir à quoi ressemble une couverture générée, puisqu'il n'y a rien à polluer.
Existe-t-il des alternatives ?
HTTPBin pour les erreurs provoquées et les codes de statut, PokeAPI pour la pagination à grande échelle, une API GitHub publique pour le comportement authentifié.
Les fausses écritures sont la meilleure leçon ici.
JSONPlaceholder vous apprend sans risque la structure des requêtes, les relations et les cas d'erreur. Ses écritures simulées mettent en évidence la différence entre une requête réussie et un changement réel, et c'est l'habitude à emporter. Passez à une API avec état dès que les bases sont acquises.