Tenho implementado vários testes de REST API de forma BDD usando Cucumber e estava pensando em um cenário em que um Activityobjeto com um determinado id pode ser recuperado por meio do GETendpoint. Um exemplo encontrado na internet verifica primeiro se uma lista de atividades está disponível, antes de realmente recuperar esse id específico.
Assim, o cenário (no arquivo de recursos) se parece com isto:
Scenario: When user requests for an existing activity id, the activity should be returned
Given A list of activities is available
When The user requests for an activity with a specific id
Then The requested activity should be returned
Na Givenetapa, enviarei uma GETsolicitação à minha API para verificar se as atividades podem ser fornecidas. Na Whenetapa, solicitarei uma atividade específica (fornecendo seu id), enquanto na Thenetapa farei minhas asserções.
Outras fontes afirmam que não é recomendado interagir diretamente com a API na Givenetapa, e apenas preparar dados internos (como criar objetos internamente ou gerar um id a ser inserido) e então enviá-los para o Then, que deve realmente fazer a interação com o sistema externo.
Minha pergunta seria: existem regras específicas sobre o que fazer no Givenpasso e o que não fazer? Se eu considerar que antes de obter uma atividade com um determinado id, eu deveria inseri-la, por exemplo, e também verificar se a inserção foi bem-sucedida, não tenho permissão para escrever a POSTlógica dentro da Givendeclaração? Se sim, isso não significa que a maioria das Givenimplementações serão vazias para APIs simples?
É uma questão de opinião.
Você prepara o sistema em teste na parte de arranjo, Dado etc. Parece-me que você está usando um cliente externo para fazer alguns testes de caixa preta em um servidor que já está em execução. Nessa situação, eu não me preocuparia muito em fazer um POST em uma etapa Dado. A menos que seja possível para você verificar o estado do servidor por algum outro canal, talvez procurando em um banco de dados ou similar.
Em outras palavras, cada situação é única e você faz o que precisa para garantir que o objetivo final seja alcançado, um sistema funcionando como os usuários finais precisam que ele funcione. Enquanto, se possível, evita pesadelos de manutenção no futuro.