O que o JSONPlaceholder oferece
Recursos previsíveis. Posts, comentários, usuários, tarefas e álbuns, com identificadores estáveis e formatos consistentes.
Todos os verbos. GET, POST, PUT, PATCH e DELETE respondem de forma coerente.
Relacionamentos aninhados. Comentários pertencem a posts, posts pertencem a usuários. Estrutura suficiente para praticar.
A lição acidental
As escritas no JSONPlaceholder são simuladas. Você faz um POST, recebe um 201 com um identificador e nada foi salvo. Busque o recurso de volta e ele não está lá.
A maioria das pessoas encara isso como uma limitação. É a coisa mais útil do serviço, porque separa duas ideias que iniciantes costumam confundir: a requisição deu certo e a mudança aconteceu. Uma suíte que faz asserções sobre códigos de status vai passar em todo teste de escrita aqui, com toda a confiança, para sempre.
Se a sua asserção sobrevive às escritas falsas do JSONPlaceholder, ela é uma asserção fraca. Reescreva-a para verificar que aquilo realmente existe depois e leve esse hábito para a sua API de verdade, onde a mesma fragilidade fica invisível.
O que praticar aqui, nesta ordem
Formatos e campos
Faça asserções sobre a estrutura do corpo da resposta, não sobre o status.
Verifique os tipos, não apenas a presença.
Relacionamentos
Busque um post, depois os comentários dele, e confira se eles realmente fazem referência a esse post.
A maioria dos bugs reais vive entre duas chamadas.
Caminhos de falha
Peça um identificador que não existe e verifique se a resposta tem o formato correto.
O teste que todo mundo pula e o que de fato pega problemas.
O que ele não consegue ensinar
Tudo o que envolve estado, ou seja, tudo o que torna difícil testar uma API de verdade. Sessões e expiração, valores capturados de uma resposta e usados na seguinte, chamadas que precisam acontecer em ordem e limpeza depois da execução. O JSONPlaceholder não tem nada disso, porque nada persiste.
Por isso ele é uma excelente primeira hora e uma segunda semana enganosa. Passe para uma API com estado real assim que o básico estiver confortável, e espere um salto de dificuldade.
Uma primeira hora que você leva adiante
Se você quer que essa prática valha alguma coisa na sua própria API, faça estes quatro passos em ordem, em vez de explorar aleatoriamente.
Busque um post e faça asserções sobre três campos específicos e seus tipos, não apenas sobre o sucesso da chamada. Busque um post que não existe e faça asserções sobre o status e sobre o formato do que volta. Busque um post, depois busque os comentários dele, e verifique que todo comentário faz referência ao post que você pediu. Então crie um post, busque-o de volta e veja a asserção falhar.
Esse último é o objetivo de todo o exercício. A escrita relatou sucesso, o identificador voltou e nada persistiu. Todo hábito que vale a pena levar para uma API de verdade está em perceber por que o seu teste passou mesmo assim e reescrevê-lo para que não passe.
Passando para um serviço real
Esses quatro pontos são o que uma camada feita para isso resolve como Auto-Authentication, Dynamic Variables, Dependency Chains e Auto-Cleanup. O funcionamento está na documentação de testes de API.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
O dashboard cobre o mesmo terreno para quem não quer instalar nada localmente, e o conjunto completo de comandos está no repositório do CLI.
O que muda quando você aponta para uma API de verdade
Tudo o que o JSONPlaceholder não consegue ensinar é o que o TestSprite resolve. Auto-Authentication para sessões que expiram no meio da execução. Dynamic Variables para o identificador que uma chamada de criação retorna. Dependency Chains para chamadas que só podem acontecer depois de outra. Auto-Cleanup para os registros que cada execução deixa para trás.
O primeiro passo é o mesmo do exercício acima: aponte um projeto para a sua URL base, deixe o API Discovery enumerar o que existe e leia o plano gerado antes de executar qualquer coisa. A diferença é que agora o plano cobre autorização e casos de limite contra um serviço em que as escritas realmente persistem.
O que você ganha é justamente aquilo para onde a prática apontava: asserções que sobrevivem ao contato com estado, rodando a cada mudança em vez de quando você lembra.
Por que minhas requisições POST não persistem?
É de propósito. O JSONPlaceholder simula as escritas. Use isso como uma lição para fazer asserções sobre resultados, não sobre respostas.
Ele serve para CI?
Para uma suíte de tutorial, ocasionalmente. Para qualquer coisa que rode a cada commit, use um mock local. É um serviço gratuito e compartilhado.
Para onde devo ir depois?
Algo com autenticação e persistência real. O salto de dificuldade é justamente o ponto, e é aí que começa a habilidade que você leva para outros contextos.
Posso apontar um gerador de testes para ele?
Pode, e é um lugar seguro para ver como é uma cobertura gerada, já que não há nada para poluir.
Existem alternativas?
HTTPBin para falhas deliberadas e códigos de status, PokeAPI para paginação em escala, uma API pública do GitHub para comportamento autenticado.
As escritas falsas são a melhor lição daqui.
O JSONPlaceholder ensina, com segurança, formatos de requisição, relacionamentos e caminhos de falha. Suas escritas simuladas expõem a diferença entre uma requisição bem-sucedida e uma mudança real, e esse é o hábito que vale a pena levar adiante. Passe para uma API com estado assim que o básico estiver dominado.