Verification and Validation (V&V) - TDD

Sobre V&V - Verificação e validação de software

É o processo no qual aferimos se as especificações e requisitos do sistema estão sendo atendidas pelo software em desenvolvimento, ou seja, a aplicação deve cumprir a finalidade pretendida. Verificação e Validação (V&V), que fazem parte da engenharia de software e também são reconhecidas como controle de qualidade, costumam fazer parte das atribuições dos testadores, como parte do ciclo de vida de desenvolvimento do projeto. De forma mais resumida podemos dizer que a Verificação busca identificar se o software atinge os objetivos propostos sem erros e/ou ausências, já a Validação verifica se o software é de fato o que deveria ter sido desenvolvido, se atende aos requisitos de alto nível.

Fonte: Wikipedia-V&V

⚗️ TDD - Test-driven development:

Consiste em um desenvolvimento guiado por testes, esse método de desenvolver software se apoia em um ciclo curto de repetições e associa-se ao conceito de verificação e validação. O código é escrito a fim de validar as necessidades descritas no teste automatizado juntamente com as do software.

Fonte: Wikipedia-TDD

✅ Autenticação e Autorização:

A autenticação no contexto do HTTP é fornecida uma estrutura geral para controle de acesso, comumente é utilizado o esquema "Basic", sendo usada para que um cliente forneça informações de autenticação e também por um servidor onde define uma solicitação do cliente. A autenticação ocorre quando o cliente inclui um campo de cabeçalho de solicitação com as credenciais, como usuário e senha.

A autorização, por sua vez, verifica nas regras de negócios se o usuário autenticado está autorizado a executar/acessar a funcionalidade/rota requisitada.

Fonte: MDN Autenticação HTTP

🏆 Desafio

Para a conclusão do capítulo 3 - Validação e Segurança do Bootcamp Spring e React - o professor Nelio Alves da Escola DevSuperior propos como desafio a tarefa abaixo.

📝 TAREFA: Validação e Segurança

Implemente as funcionalidades necessárias para que os testes do projeto bds04 sejam executados sem falhas: https://github.com/devsuperior/bds04

Neste sistema, somente as rotas de leitura de eventos e cidades são públicas. Usuários CLIENT podem também inserir novos eventos. Os demais acessos são permitidos apenas a usuários ADMIN.

Validações de City:

Nome não pode ser vazio

Validações de Event:

Nome não pode ser vazio
Data não pode ser passada
Cidade não pode ser nula

Resolução

Na aplicação continha apenas as entidades e o DTO de City e Events implementados, juntamente com os testes. Após analisar o conteúdo da aplicação e os testes resolvi seguir a seguinte ordem de implementação dos códigos:

Modelo de dados User-Roles;
Adicionar pacotes Repository, Services, Controllers e pacotes de exceção para Services e Controllers;
Infraestrutura de validação;
Infraestrutura de segurança;
Releitura dos testes, implementar funcionalidades e executar testes.

🚧 Modelo de dados User-Roles

Modelo de dados User-Roles incluídos e verificados no banco de dados H2. Neste primeiro passo decidi utilizar um código provisório para liberação dos endpoints, conforme explicado pelo professor Nélio, desta forma consegui verificar se as tabelas foram inseridas corretamente no H2. Se não inserisse essas informações todos os caminhos estariam bloqueados, pois o pom.xml já está com todas as bibliotecas de segurança, spring-boot-starter-validation, spring-boot-starter-validation e spring-security-oauth2-autoconfigure.

🚧 Adicionar pacotes Repository, Services, Controllers e pacotes de exceção para Services e Controllers

Na aplicação continha apenas os pacotes entities e o dto, sendo necessário adicionar todos os demais pacotes como, Repository, Services, Controllers, bem como as exceções do Controllers e Services. Após a implementação dos pacotes todos os endpoints foram verificados no Postman.

🚧 Infraestrutura de validação

Infraestrutura de validação incluída ao projeto, composta pelos arquivos FieldMessage, ValidationError e o método MethodArgumentNotValidException no ControllerExceptionHandler, este último, inclusive, é de extrema importância para as validações.

🚧 Infraestrutura de segurança

Infraestrutura de segurança adicionada ao projeto, incluindo variáveis de ambiente no application.properties, retirada do arquivo provisório SecurityConfig que liberava os endpoints.

Criada a classe UserService que implementa as interfaces do Spring Security, UserDetails e UserDetailsService, juntamente com a WebSecurityConfigurerAdapter, classe para configuração de segurança web onde é necessário implementar o AuthenticationManager.

Já no AppConfig conterá algumas configurações do aplicativo como os Beans BCrypt, JwtAccessTokenConverter e JwtTokenStore. E concluindo a infraestrutura foi incluído AuthorizationServerConfigurerAdapter que é a classe de configuração para Authorization Server e ResourceServerConfigurerAdapter que é a classe de configuração para Resource Server. 🤯

🚧 Releitura dos testes, implementar funcionalidades e executar testes

Teste de Integração CityController:

Deve retornar 401 (Unauthorized) quando um usuário não logado tentar inserir uma cidade.
Deve retornar 403 (Forbidden) quando um Client logado tentar inserir uma cidade.
Deve retornar 201 (Created), inserir a cidade, quando o Admin estiver logado e os dados estiverem corretos.
Deve retornar 422 (Unprocessable Entity) quando Admin estiver logado, mas tentar inserir a cidade com o nome em branco.
Deve retornar uma lista com todas as cidades ordenadas por nome.

Teste de Integração EventController:

Deve retornar 401 (Unauthorized) quando o usuário não logado tentar inserir um evento.
Deve retornar 201 (Created), inserir o evento, quando o Client estiver logado e os dados estiverem corretos.
Deve retornar 201 (Created), inserir o evento, quando o Admin estiver logado e os dados estiverem corretos.
Deve retornar 422 (Unprocessable Entity) quando Admin estiver logado, mas tentar inserir o nome do evento em branco.
Deve retornar 422 (Unprocessable Entity) quando Admin estiver logado, mas tentar inserir o evento com data passada.
Deve retornar 422 (Unprocessable Entity) quando Admin estiver logado, mas tentar inserir o evento sem informar a cidade.
Deve retornar os eventos de forma paginada.

Fonte: Códigos de status de respostas HTTP

🚀 Tecnologias

Java 11
Spring boot
JPA
Maven
OAuth 2.0
JWT

🕹 Execução

Pré-requisitos: Java 11 e Postman (ou a API Client que preferir)

# Clonar repositório
git clone https://github.com/lilianmartinsfritzen/TDD-ValidationAndSecurity
# Entrar na pasta abaixo
cd bds04
# Executar o projeto
./mvnw spring-boot:run

# Caminhos utilizados no Postman
GET - All Cities: http://localhost:8080/cities
GET - Events Paged: http://localhost:8080/events

# Dados para Login
POST - LOGIN: http://localhost:8080
ENDPOINT: /oauth/token (Utilizado o padrão OAuth)

AUTHORIZATION: 
Type: Basic Auth

USERNAME	PASSWORD
myclientid	myclientsecret

Body: x-www-form-urlencoded
Ana - CLIENT

KEY	VALUE	DESCRIPTION
username	ana@gmail.com
password	123456
grand_type	password

Body: x-www-form-urlencoded
Bob - ADMIN

KEY	VALUE	DESCRIPTION
username	bob@gmail.com
password	123456
grand_type	password

# Caminhos utilizados com Body
POST - New City: http://localhost:8080/cities

{
  "name": "New city"
}


POST - New Event: http://localhost:8080/events

{
  "name": "Novo evento",
  "url": "https://novoevento.com.br",
  "date": "2023-07-15",
  "cityId": 1
}

📃 Licença

Esse projeto está sob a licença MIT. Veja o arquivo LICENSE para mais detalhes.

lilianmartinsfritzen/TDD-ValidationAndSecurity