Casos de Teste - douglaslang01/pace-connect-api GitHub Wiki
Os casos de teste deste projeto foram desenvolvidos utilizando a linguagem Gherkin. Cada caso foi cuidadosamente elaborado e organizado por endpoint, facilitando a manutenção e a rastreabilidade dos testes.
Toda a documentação dos testes está disponível na pasta test\features, localizada no repositório oficial do projeto no GitHub. Além disso, todos os cenários foram automatizados, garantindo maior eficiência e confiabilidade no processo de validação das funcionalidades.
US01 - Registro de Usuários: registerUser.feature
Casos de Teste
Feature: Registro de Usuário
Scenario: CT01: Cadastro de usuário válido
Given que o sistema está disponível
When envio uma requisição POST para "/users/register" com os dados:
| usuario | senha | nascimento | sexo | experiencia | objetivo | pace | tipo |
| aluno10 | 123456 | 2000-01-01 | M | iniciante | saúde | 300 | aluno |
Then o sistema deve retornar status 201
And o usuário deve ser cadastrado com id incremental
Scenario: CT02: Campos obrigatórios ausentes
Given que o sistema está disponível
When envio uma requisição POST para "/users/register" com os dados:
| usuario | senha | nascimento | sexo | experiencia | objetivo | pace | tipo |
| | | 2000-01-01 | M | iniciante | saúde | 300 | aluno |
Then o sistema deve retornar status 400
And deve exibir mensagem "Erro ao registrar usuário"
Scenario: CT03: Data de nascimento inválida
Given que o sistema está disponível
When envio uma requisição POST para "/users/register" com os dados:
| usuario | senha | nascimento | sexo | experiencia | objetivo | pace | tipo |
| aluno3 | 123456 | invalid-date | F | iniciante | saúde | 300 | aluno |
Then o sistema deve retornar status 400
And deve exibir mensagem "Erro ao registrar usuário"
Scenario: CT04: Valor inválido para sexo
Given que o sistema está disponível
When envio uma requisição POST para "/users/register" com os dados:
| usuario | senha | nascimento | sexo | experiencia | objetivo | pace | tipo |
| aluno4 | 123456 | 2000-01-01 | X | iniciante | saúde | 300 | aluno |
Then o sistema deve retornar status 400
And deve exibir mensagem "Erro ao registrar usuário"
Scenario: CT05: Tipo inválido para pace
Given que o sistema está disponível
When envio uma requisição POST para "/users/register" com os dados:
| usuario | senha | nascimento | sexo | experiencia | objetivo | pace | tipo |
| aluno5 | 123456 | 2000-01-01 | M | iniciante | saúde | cinco | aluno |
Then o sistema deve retornar status 400
And deve exibir mensagem "Erro ao registrar usuário"
Scenario: CT06: Valor inválido para campo tipo
Given que o sistema está disponível
When envio uma requisição POST para "/users/register" com os dados:
| usuario | senha | nascimento | sexo | experiencia | objetivo | pace | tipo |
| aluno7 | 123456 | 2000-01-01 | M | iniciante | saúde | 300 | admin |
Then o sistema deve retornar status 400
And deve exibir mensagem "Erro ao registrar usuário"
Scenario: CT07: Usuário já existente
Given que o sistema está disponível
When envio uma requisição POST para "/users/register" com os dados:
| usuario | senha | nascimento | sexo | experiencia | objetivo | pace | tipo |
| aluno01 | 123456 | 2000-01-01 | M | iniciante | saúde | 300 | aluno |
Then o sistema deve retornar status 400
And deve exibir mensagem "Erro ao registrar usuário"
US02- Login do Usuário: login.feature
Casos de Teste
Feature: Login do Usuário
Scenario: CT08: Login com usuário e senha válidos
Given o usuário "aluno1" e senha "123456" está cadastrado
When envio uma requisição POST para "/users/login" com os dados:
| usuario | senha |
| aluno1 | 123456 |
Then o sistema deve retornar status 200
And o token JWT deve ser retornado
Scenario: CT09: Login com senha incorreta
Given o usuário "aluno1" e senha "123456" está cadastrado
When envio uma requisição POST para "/users/login" com os dados:
| usuario | senha |
| aluno1 | xyz |
Then a resposta deve ter status 401
And mensagem de erro "Credenciais inválidas"
Scenario: CT10: Login com usuario incorreto
Given o usuário "aluno1" e senha "123456" está cadastrado
When envio uma requisição POST para "/users/login" com os dados:
| usuario | senha |
| xyz | 123456 |
Then a resposta deve ter status 401
And mensagem de erro "Credenciais inválidas"
Scenario: CT11: Login com password numérico (tipo inválido)
Given o usuário "aluno1" e senha "123456" está cadastrado
When envio uma requisição POST para "/users/login" com os dados:
| usuario | senha |
| aluno1 | 123456 |
Then a resposta deve ter status 500
US03 - Consulta de dados do Usuários: listUsers.feature
Casos de Teste
Feature: Consulta de Usuários
Scenario: CT12 - Busca de usuários autenticado
Given que o sistema está disponível
And estou autenticado com um token válido
When envio uma requisição GET para "/users" com o header Authorization: Bearer <token válido>
Then o sistema deve retornar status 200
And o corpo da resposta deve conter uma lista de todos os usuários (alunos e treinadores) em formato "JSON"
Scenario: CT13 - Busca de usuários sem autenticação
Given que o sistema está disponível
When envio uma requisição GET para "/users" sem o header Authorization
Then o sistema deve retornar status 401
And deve exibir mensagem de autenticação obrigatória
@focus
Scenario: CT14 - Busca de usuários com token inválido
Given que o sistema está disponível
When envio uma requisição GET para "/users" com o header Authorization: Bearer <token inválido>
Then o sistema deve retornar status 403
And deve exibir mensagem de token inválido
Feature: Consulta de Usuário por ID
Scenario: CT15 - Busca de usuário por ID autenticado
Given que o sistema está disponível
And estou autenticado com um token válido
When envio uma requisição GET para "/users/{id}" com o header Authorization: Bearer <token válido>
Then o sistema deve retornar status 200
And o corpo da resposta deve conter os dados completos do usuário correspondente ao ID em formato "JSON"
Scenario: CT16 - Busca de usuário por ID sem autenticação
Given que o sistema está disponível
When envio uma requisição GET para "/users/{id}" sem o header Authorization
Then o sistema deve retornar status 401
And deve exibir mensagem de autenticação obrigatória
Scenario: CT17 - Busca de usuário por ID com token inválido
Given que o sistema está disponível
When envio uma requisição GET para "/users/{id}" com o header Authorization: Bearer <token inválido>
Then o sistema deve retornar status 403
And deve exibir mensagem de token inválido
Scenario: CT18 - Busca de usuário por ID inexistente
Given que o sistema está disponível
And estou autenticado com um token válido
When envio uma requisição GET para "/users/{id inexistente}" com o header Authorization: Bearer <token válido>
Then o sistema deve retornar status 404
And deve exibir mensagem de usuário não encontrado
Scenario: CT19 - Busca de usuário por ID com formato inválido
Given que o sistema está disponível
And estou autenticado com um token válido
When envio uma requisição GET para "/users/abc" com o header Authorization: Bearer <token válido>
Then o sistema deve retornar status 400
And deve exibir mensagem de formato inválido para ID
US04 - Registro de Treinos: registerTraining.feature
Casos de Teste
Feature: Registro de Treinos
Scenario: CT20 - Registro de treino válido
Given que o usuário está autenticado com um token válido
When envio uma requisição POST para "/trainings" com os dados:
| dataHora | distancia | tempoTotal | pace |
| 2025-11-04T08:00:00 | 10 | 01:00:00 | 360 |
Then o sistema deve retornar status 201
And o treino deve ser cadastrado com id incremental
And o corpo da resposta deve estar em formato "JSON"
Scenario: CT21 - Registro de treino sem autenticação
Given que o usuário não está autenticado
When envio uma requisição POST para "/trainings" com os dados:
| dataHora | distancia | tempoTotal | pace |
| 2025-11-04T08:00:00 | 10 | 01:00:00 | 360 |
Then o sistema deve retornar status 401
And deve exibir mensagem de autenticação obrigatória
Scenario: CT22 - Registro de treino com token inválido
Given que o usuário está autenticado com um token inválido
When envio uma requisição POST para "/trainings" com os dados:
| dataHora | distancia | tempoTotal | pace |
| 2025-11-04T08:00:00 | 10 | 01:00:00 | 360 |
Then o sistema deve retornar status 403
And deve exibir mensagem de token inválido
Scenario: CT23 - Registro de treino com dados ausentes
Given que o usuário está autenticado com um token válido
When envio uma requisição POST para "/trainings" com os dados:
| dataHora | distancia | tempoTotal | pace |
| | | | |
Then o sistema deve retornar status 400
And deve exibir mensagem de campos obrigatórios ausentes (distancia e pace)
Scenario: CT24 - Registro de treino com formato inválido
Given que o usuário está autenticado com um token válido
When envio uma requisição POST para "/trainings" com os dados:
| dataHora | distancia | tempoTotal | pace |
| invalid-date | dez | abc | string |
Then o sistema deve retornar status 400
And deve exibir mensagem de formato inválido
Scenario: CT25 - Registro de treino com valores não permitidos
Given que o usuário está autenticado com um token válido
When envio uma requisição POST para "/trainings" com os dados:
| dataHora | distancia | tempoTotal | pace |
| 2025-11-04T08:00:00 | 0 | 01:00:00 | 0 |
Then o sistema deve retornar status 400
And deve exibir mensagem indicando que "distancia" e "pace" devem ser maiores que 0
Scenario: CT26 - Registro de treino sem distancia e pace
Given que o usuário está autenticado com um token válido
When envio uma requisição POST para "/trainings" com os dados:
| dataHora | tempoTotal |
| 2025-11-04T08:00:00 | 01:00:00 |
Then o sistema deve retornar status 400
And deve exibir mensagem de campos obrigatórios ausentes (distancia e pace)
US05 - Consulta de Treinos próprios: listMyTrainings.feature
Casos de Teste
Feature: Consulta de Treinos do Usuário Logado
Scenario: CT27 - Busca de treinos autenticado
Given que o usuário está autenticado com um token válido
And existem treinos cadastrados para o usuário logado
When envio uma requisição GET para "/trainings/mine" com o header Authorization
Then o sistema deve retornar status 200
And o corpo da resposta deve conter uma lista de todos os treinos do usuario logado em formato "JSON"
Scenario: CT28 - Busca de treinos sem autenticação
Given que o usuário não está autenticado
When envio uma requisição GET para "/trainings/mine" sem o header Authorization
Then o sistema deve retornar status 401
And deve exibir mensagem de autenticação obrigatória
Scenario: CT29 - Busca de treinos com token inválido
Given que o usuário está autenticado com um token inválido
When envio uma requisição GET para "/trainings/mine" com o header Authorization inválido
Then o sistema deve retornar status 403
And deve exibir mensagem de token inválido
Scenario: CT30 - Busca treinos do usuário logado
Given que o usuário "aluno1" está autenticado e possui treinos cadastrados
And existe um usuário "treinador1" também logado ao sistema
And envio de treinos para o usuário "treinador1"
When envio uma requisição GET para "/trainings/mine" autenticado como "aluno1"
Then o sistema deve retornar status 200
And o corpo da resposta deve conter apenas os treinos do usuário "aluno1"
US06 - Consulta de Treinos por ID do Usuário: listTrainingsByUserId.feature
Casos de Teste
Feature: Consulta de Treinos por ID do Usuário
Scenario: CT31 - Busca de treinos por ID autenticado
Given que o usuário está autenticado com um token válido
And existe um usuário com ID 1 que possui treinos cadastrados
When envio uma requisição GET para "/trainings/user/1" com o header Authorization: Bearer <token válido>
Then o sistema deve retornar status 200
And o corpo da resposta deve conter a lista dos treinos do usuário informado em formato "JSON"
Scenario: CT32 - Busca de treinos por ID sem autenticação
Given que não estou autenticado
When envio uma requisição GET para "/trainings/user/1" sem o header Authorization
Then o sistema deve retornar status 401
And deve exibir mensagem de autenticação obrigatória
Scenario: CT33 - Busca de treinos por ID com token inválido
Given que estou autenticado com um token inválido
When envio uma requisição GET para "/trainings/user/1" com o header Authorization: Bearer <token inválido>
Then o sistema deve retornar status 403
And deve exibir mensagem de token inválido
Scenario: CT34 - Busca de treinos por ID inexistente
Given que estou autenticado com um token válido
And não existem treinos cadastrados para o usuário de ID 999
When envio uma requisição GET para "/trainings/user/999" com o header Authorization: Bearer <token válido>
Then o sistema deve retornar status 200
And o corpo da resposta deve conter uma lista vazia
Scenario: CT35 - Busca de treinos por ID com formato inválido
Given que estou autenticado com um token válido
When envio uma requisição GET para "/trainings/user/abc" com o header Authorization: Bearer <token válido>
Then o sistema deve retornar status 400
And deve exibir mensagem de formato inválido para userId
US07 - Exclusão de Treinos: deleteTrainingById.feature
Casos de Teste
Feature: Exclusão de Treinos
Scenario: CT36 - Exclusão de treino autenticado
Given que o usuário está autenticado com um token válido
And existe um treino com ID 1 cadastrado para o usuário logado
When envio uma requisição DELETE para "/trainings/1" com o header Authorization: Bearer <token válido>
Then o sistema deve retornar status 204
And o treino deve ser removido com sucesso
Scenario: CT37 - Exclusão de treino sem autenticação
Given que não estou autenticado
When envio uma requisição DELETE para "/trainings/1" sem o header Authorization
Then o sistema deve retornar status 401
And deve exibir mensagem de autenticação obrigatória
Scenario: CT38 - Exclusão de treino com token inválido
Given que estou autenticado com um token inválido
When envio uma requisição DELETE para "/trainings/1" com o header Authorization: Bearer <token inválido>
Then o sistema deve retornar status 403
And deve exibir mensagem de token inválido
Scenario: CT39 - Exclusão de treino inexistente
Given que estou autenticado com um token válido
And não existe treino com ID 999 cadastrado para o usuário logado
When envio uma requisição DELETE para "/trainings/999" com o header Authorization: Bearer <token válido>
Then o sistema deve retornar status 404
And deve exibir mensagem de treino não encontrado
Scenario: CT40 - Exclusão de treino com formato inválido para ID
Given que estou autenticado com um token válido
When envio uma requisição DELETE para "/trainings/abc" com o header Authorization: Bearer <token válido>
Then o sistema deve retornar status 404
And deve exibir mensagem de treino não encontrado
US09 - Agrupamento de alunos por pace: workoutGroup.feature
Casos de Teste
Feature: Agrupamento de alunos por pace
Scenario: CT41 - Agrupamento sem autenticação
Given que não estou autenticado
When envio uma requisição GET para "/trainings/group" sem o header Authorization
Then o sistema deve retornar status 401
And deve exibir mensagem de autenticação obrigatória
Scenario: CT42 - Agrupamento com token inválido
Given que estou autenticado com um token inválido
When envio uma requisição GET para "/trainings/group" com o header Authorization: Bearer <token inválido>
Then o sistema deve retornar status 403
And deve exibir mensagem de token inválido
Scenario: CT43 - Agrupamento de alunos por pace
Given que estou autenticado com um token válido
And existem alunos cadastrados com diferentes valores de pace
When envio uma requisição GET para "/trainings/group" com o header Authorization: Bearer <token válido>
Then o sistema deve retornar status 200
And o corpo da resposta deve conter grupos como "300-330"
And o pace de cada aluno deve estar dentro do intervalo do grupo correspondente
Scenario: CT44 - Validação dos intervalos de agrupamento
Given que estou autenticado com um token válido
And existem alunos cadastrados com diferentes valores de pace
When envio uma requisição GET para "/trainings/group" com o header Authorization: Bearer <token válido>
Then o sistema deve retornar status 200
And os grupos retornados devem ter intervalos de 30 em 30 segundos, por exemplo: "300-330", "330-360"
US08 - Consolidação do Pace por Aluno: consolidatePace.feature
Casos de Teste
Feature: Consolidação do Pace por Aluno
Scenario: CT45 - Consolidação de pace com treinos nos últimos 30 dias
Given que estou autenticado com um token válido
And o usuário de ID 1 possui treinos completos nos últimos 30 dias
When envio uma requisição GET para "/trainings/consolidate/1" com o header Authorization: Bearer <token válido>
Then o sistema deve retornar status 200
And o pace consolidado deve ser calculado apenas com os treinos dos últimos 30 dias
And o pace consolidado deve ser atualizado no cadastro do usuário
Scenario: CT46 - Consolidação de pace sem treinos nos últimos 30 dias
Given que estou autenticado com um token válido
And o usuário de ID 3 não possui treinos completos nos últimos 30 dias
When envio uma requisição GET para "/trainings/consolidate/2" com o header Authorization: Bearer <token válido>
Then o sistema deve retornar status 404
And deve exibir mensagem de Sem treinos válidos para consolidação
And o pace consolidado não deve ser alterado
And o cadastro do usuário deve permanecer igual
Scenario: CT47 - Consolidação de pace ignorando treinos incompletos
Given que estou autenticado com um token válido
And o usuário de ID 4 possui treinos incompletos (sem distância ou pace) e completos nos últimos 30 dias
When envio uma requisição GET para "/trainings/consolidate/3" com o header Authorization: Bearer <token válido>
Then o sistema deve retornar status 200
And o pace consolidado deve ser calculado apenas com treinos completos
And o pace consolidado deve ser atualizado no cadastro do usuário
Scenario: CT48 - Consolidação de pace sem autenticação
Given que não estou autenticado
When envio uma requisição GET para "/trainings/consolidate/1" sem o header Authorization
Then o sistema deve retornar status 401
And deve exibir mensagem de autenticação obrigatória
Scenario: CT49 - Consolidação de pace com token inválido
Given que estou autenticado com um token inválido
When envio uma requisição GET para "/trainings/consolidate/1" com o header Authorization: Bearer <token inválido>
Then o sistema deve retornar status 403
And deve exibir mensagem de token inválido
Scenario: CT50 - Consolidação de pace para usuário inexistente
Given que estou autenticado com um token válido
And o usuário de ID 999 não existe
When envio uma requisição GET para "/trainings/consolidate/999" com o header Authorization: Bearer <token válido>
Then o sistema deve retornar status 404
And deve exibir mensagem de usuário não encontrado
Scenario: CT51 - Consolidação de pace com formato inválido para userId
Given que estou autenticado com um token válido
When envio uma requisição GET para "/trainings/consolidate/abc" com o header Authorization: Bearer <token válido>
Then o sistema deve retornar status 400
And deve exibir mensagem de formato inválido para userId