Cenário: Criar usuário com dados válidos [FALHA]
Dado que possuo uma massa de dados válida
Quando envio uma requisição POST para /api/user/create
Então o sistema deve retornar o status 201 Created
E o corpo da resposta deve conter o id_user gerado
E o nome retornado deve ser igual ao enviado
(Está retornando 200, mas cria o usuário)
Cenário: Consultar usuário recém criado [SUCESSO]
Dado que possuo um ID de usuário válido criado anteriormente
Quando envio uma requisição GET para /api/user/{id}
E clico diretamente no botão de salvar sem preencher nenhum campo
Então o sistema deve retornar o status 200 OK
E os dados devem corresponder ao cadastro
Cenário: Listar todos os usuários [SUCESSO]
Dado que existem usuários cadastrados no banco de dados
Quando envio uma requisição GET para /api/user
Então o sistema deve retornar o status 200 OK
E o corpo da resposta deve ser uma lista (Array) de usuários
Cenário: Atualização parcial de usuário (PATCH) [FALHA]
Dado que possuo um usuário cadastrado
Quando envio uma requisição PATCH para /api/user/{id}/update
Então o sistema deve retornar o status 200 OK
E o nome do usuário deve ser atualizado no banco
Cenário: Validar obrigatoriedade dos campos no cadastro [FALHA]
Dado que desejo cadastrar um novo usuário
Quando envio uma requisição POST para /api/user/create omitindo um dos campos obrigatórios abaixo
Então o sistema não deve criar o registro (Status diferente de 200/201)
E deve retornar uma mensagem de erro apropriada
| Tentativa | Campo Omitido | Resultado Esperado |
|---|---|---|
| 5.1 | Nome | Erro / Não Criar |
| 5.2 | Erro / Não Criar | |
| 5.3 | Telefone | Erro / Não Criar |
| 5.4 | Data de Nascimento | Erro / Não Criar |
| 5.5 | Cidade de Nascimento | Erro / Não Criar |
| 5.6 | Empresa (companies) | Erro / Não Criar |
Cenário: Impedir cadastro com E-mail duplicado [FALHA]
Dado que já existe um usuário cadastrado com o e-mail "[email protected]"
Quando envio uma requisição POST para /api/user/create utilizando este mesmo e-mail no corpo da requisição
Então o sistema deve rejeitar a requisição (Status 400, 409 ou 422)
E não deve gerar um novo ID
Cenário: Impedir cadastro com Telefone duplicado [FALHA]
Dado que já existe um usuário com o telefone "51999999999"
Quando envio uma requisição POST para /api/user/create utilizando este mesmo telefone no corpo da requisição
Então o sistema deve rejeitar a requisição (Status 400, 409 ou 422)
E não deve gerar um novo ID
Cenário: Validar formato do E-mail [FALHA]
Dado que informo um e-mail com formato inválido (ex: "email-sem-arroba.com") no corpo da requisição
Quando envio uma requisição POST para /api/user/create
Então o sistema deve rejeitar o cadastro retornando status 400 Bad Request ou 422 Unprocessable Entity
Cenário: Validar formato do Telefone [FALHA]
Dado que informo um telefone contendo letras (ex: "abcde-erro") no corpo da requisição
Quando envio uma requisição POST para /api/user/create
Então o sistema deve rejeitar o cadastro retornando status 400 Bad Request ou 422 Unprocessable Entity
Cenário: Validar Data de Nascimento Futura [FALHA]
Dado que informo uma data de nascimento maior que a data atual (Data Futura)
Quando envio uma requisição POST para /api/user/create
Então o sistema deve rejeitar o cadastro retornando status 400 Bad Request ou 422 Unprocessable Entity
Cenário: Excluir usuário existente [SUCESSO]
Dado que possuo um ID de usuário válido
Quando envio uma requisição DELETE para /api/user/{id}/delete
Então o sistema deve retornar status 200 OKE ao consultar este ID novamente via GET, o sistema não deve retornar os dados do usuário
Cenário: Tentar excluir usuário inexistente [SUCESSO]
Dado que informo um ID que não existe no banco (ex: 999999)
Quando envio uma requisição DELETE para /api/user/{id}/delete
Então o sistema deve retornar um erro com status 404 Not Found ou 400 Bad Request
E não deve retornar status 200 OK (para garantir que não houve um falso positivo)