Lo que te da JSONPlaceholder
Recursos predecibles. Posts, comentarios, usuarios, tareas y álbumes, con identificadores estables y estructuras consistentes.
Todos los verbos. GET, POST, PUT, PATCH y DELETE responden de forma razonable.
Relaciones anidadas. Los comentarios pertenecen a posts y los posts, a usuarios. Estructura suficiente para practicar.
La lección accidental
Las escrituras en JSONPlaceholder son simuladas. Haces un POST, recibes un 201 con un identificador y no se guardó nada. Lo vuelves a pedir y no está.
La mayoría lo trata como una limitación. Es lo más útil de todo el servicio, porque separa dos ideas que quienes empiezan confunden una y otra vez: la petición tuvo éxito y el cambio ocurrió. Una suite que hace sus aserciones sobre códigos de estado pasará aquí todas las pruebas de escritura, con total seguridad, para siempre.
Si tu aserción sobrevive a las escrituras falsas de JSONPlaceholder, es una aserción débil. Reescríbela para comprobar que aquello existe de verdad después, y llévate ese hábito a tu API real, donde esa misma debilidad es invisible.
Qué practicar aquí, y en qué orden
Estructuras y campos
Haz tus aserciones sobre la estructura del cuerpo, no sobre el código de estado.
Comprueba los tipos, no solo que el campo esté.
Relaciones
Pide un post, luego sus comentarios, y comprueba que de verdad lo referencian.
La mayoría de los errores reales viven entre dos llamadas.
Rutas de error
Pide un identificador que no existe y comprueba que la respuesta tiene la forma correcta.
La prueba que la gente se salta y la que detecta cosas.
Lo que no puede enseñar
Todo lo que tiene estado, que es justo lo que hace difícil probar una API real. Sesiones y caducidad, valores capturados de una respuesta y usados en la siguiente, llamadas que deben ocurrir en orden y limpieza después de una ejecución. JSONPlaceholder no tiene nada de esto porque nada persiste.
Así que es una primera hora excelente y una segunda semana engañosa. Pasa a una API con estado real en cuanto lo básico te resulte cómodo, y cuenta con que la dificultad dé un salto.
Una primera hora que sí te sirve después
Si quieres que la práctica valga algo en tu propia API, haz estos cuatro pasos en orden en lugar de explorar al azar.
Pide un post y haz aserciones sobre tres campos concretos con sus tipos, no solo sobre que la llamada haya funcionado. Pide un post que no existe y haz aserciones sobre el estado y sobre la forma de lo que vuelve. Pide un post, luego pide sus comentarios y comprueba que cada comentario referencia el post que pediste. Después crea un post, vuelve a pedirlo y mira cómo falla la aserción.
Ese último es el sentido de todo el ejercicio. La escritura informó de éxito, el identificador volvió y nada persistió. Todo hábito que merezca la pena llevar a una API real está en darte cuenta de por qué tu prueba pasó igualmente y en reescribirla para que deje de hacerlo.
Pasar a un servicio real
Esos cuatro puntos son lo que una capa creada para ello resuelve como Auto-Authentication, Dynamic Variables, Dependency Chains y Auto-Cleanup. El funcionamiento está en la documentación de pruebas de API.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
El panel cubre lo mismo para quien no quiera una instalación local, y toda la superficie de comandos está en el repositorio del CLI.
Qué cambia cuando lo apuntas a una API real
Todo lo que JSONPlaceholder no puede enseñar es de lo que se encarga TestSprite. Auto-Authentication para sesiones que caducan a mitad de una ejecución. Dynamic Variables para el identificador que devuelve una llamada de creación. Dependency Chains para llamadas que no pueden ocurrir hasta que haya ocurrido otra cosa. Auto-Cleanup para los registros que deja atrás cada ejecución.
El primer movimiento es el mismo que en el ejercicio de arriba: apunta un proyecto a tu URL base, deja que API Discovery enumere lo que existe y lee el plan generado antes de ejecutar nada. La diferencia es que ahora el plan cubre casos de autorización y casos límite contra un servicio donde las escrituras sí persisten.
Lo que ganas es aquello hacia lo que apuntaba toda la práctica: aserciones que sobreviven al contacto con el estado y que se ejecutan en cada cambio, no cuando te acuerdas.
¿Por qué no persisten mis peticiones POST?
Es a propósito. JSONPlaceholder simula las escrituras. Úsalo como lección para hacer aserciones sobre los resultados y no sobre las respuestas.
¿Sirve para CI?
Para una suite de tutorial, de vez en cuando. Para cualquier cosa que se ejecute en cada commit, usa mejor un mock local. Es un servicio gratuito y compartido.
¿A qué debería pasar después?
A algo con autenticación y persistencia real. El salto de dificultad es justo el punto, y ahí es donde empieza la habilidad que sí se transfiere.
¿Puedo apuntarle un generador de pruebas?
Sí, y es un sitio seguro para ver qué aspecto tiene la cobertura generada, porque no hay nada que contaminar.
¿Hay alternativas?
HTTPBin para fallos y códigos de estado deliberados, PokeAPI para paginación a escala, una API pública de GitHub para comportamiento autenticado.
Las escrituras falsas son la mejor lección que hay aquí.
JSONPlaceholder enseña estructuras de petición, relaciones y rutas de error de forma segura. Sus escrituras simuladas dejan ver la diferencia entre una petición con éxito y un cambio real, que es el hábito que merece la pena llevarse. Pasa a una API con estado en cuanto lo básico esté asentado.