Escrito por: Emre Savcı

Neste artigo, mostrarei como escrever testes unitários em aplicações do SpringBoot.

A razão da necessidade de escrever testes unitários pede um outro artigo para explicar. Para uma breve explicação, no entanto, vou contar a você algumas coisas.

Normalmente, eu defendo o argumento de que um código sem testes unitários é um código morto. Isso porque, quando um desenvolvedor adiciona uma nova funcionalidade a um código que não é coberta por testes unitários, fica propenso a sobrescrever alguma regra de negócio (o que mata o código que foi escrito anteriormente). Talvez não fique exatamente propenso, mas você consegue imaginar que podem acontecer erros quando um projeto precisar ser modificado. Testes unitários são a única forma de proteger seu código contra quebras que podem ocorrer em mudanças.

Por que testes unitários em enpoints?

Toda vez que escrevemos um endpoint, precisamos ter certeza de que algumas coisas estão funcionando corretamente. O endpoint deve retornar os dados em uma estrutura correta e lidar com a requisição corretamente. Podemos testar manualmente, o que não é preferível. Então, escrevemos testes unitários para garantir que nossos endpoints funcionam corretamente. Existe também uma forma de testar endpoints usando testes automatizados, mas não é o objetivo deste artigo.

Por que testes unitário em serviços?

Isso já deveria ser claro, mas, em todo caso: precisamos ter certeza que nossa regra de negócio funciona corretamente.

Por que testes unitários em repositórios?

Existem alguns casos para testar repositórios. É claro que não testamos o próprio framework. Porém, escrevemos testes unitários para ter a certeza de que nossas especificações ou relações foram implementadas corretamente.

Como testamos controllers?

Agora é a hora de mostrar a você como testar nossos controllers no SpringBoot. Vamos imaginar que escrevemos uma aplicação que nos permite salvar usuários no nosso banco de dados. Definimos uma entidade user (usuário), um serviço para o usuário e um controller.

Observação: os exemplos demonstrados nesse artigo não são para arquiteturas de aplicações reais em produção.

@Data@Entitypublic class User {    @Id    @GeneratedValue(generator = "uuid2")    @GenericGenerator(name = "uuid2", strategy = "org.hibernate.id.UUIDGenerator")    @Column(name = "id", columnDefinition = "BINARY(16)")    private UUID id;    private String name;    private String email;    private int age;}

@Datapublic class CreateUserRequest {    private String name;    private String email;    private int age;}

@RestController@RequestMapping("/users")public class UserController {    UserService userService;    @Autowired    public UserController(UserService userService) {        this.userService = userService;    }    @PostMapping    public ResponseEntity<User> createUser(@RequestBody CreateUserRequest request) {        User created = userService.save(request);        return ResponseEntity.ok(created);    }}

Nossos controllers tem uma dependência no UserService, mas não estamos interessados no que o serviço faz agora.

Agora vamos escrever um teste unitário para nosso controller e garantir que ele funciona corretamente.

Simulamos nosso serviço porque ainda não temos sua implementação em detalhes. Testamos nosso controller apenas aqui. Usamos o MockMvc para testar nosso controller e mapear nosso objeto para fins de serialização.

Configuramos o método userService.Save() para retornar nosso objeto user desejado. Passamos uma requisição para nosso controller e depois verificamos os dados retornados na seguinte linha:

andExpect(jsonPath("$.name").value(request.getName())) .

Também temos outros métodos que podem ser usados (documentação do Spring Boot, em inglês). Aqui está a lista:

Quando executamos o teste, vemos que ele passa:

Como testamos nosso serviço?

Agora, vamos testar o UserService. Ele é bem simples de testar.

Simulamos um repositório e injetamos nele um UserService. Agora, quando executarmos o teste, veremos que ele passa.

Vamos adicionar uma regra de negócio ao UserService: digamos que o usuário precisa ter um endereço de e-mail.

Vamos mudar nosso método de salvamento no UserService:

public User save(CreateUserRequest request) {    requireNonNull(request.getEmail());        User user = new User();    user.setName(request.getName());    user.setEmail(request.getEmail());    user.setAge(request.getAge());    userRepository.save(user);    return user;}

Quando executamos o teste novamente, veremos que o teste falha.

Antes de consertarmos, vamos escrever um teste que satisfaça essa regra.

Escrevemos um novo teste que especificou que, se enviarmos um e-mail nulo, ele lançará uma NullPointerException.

Vamos agora consertar o teste adicionando um e-mail à nossa requisição:

createUserRequest.setEmail("testemail");

Executando ambos os testes:

Como testamos nossos repositórios?

Agora, vamos testar nossos repositórios. Vamos usar um banco de dados h2 em memória com TestEntityManager.

Nosso repositório é definido assim:

@Repositorypublic interface UserRepository extends JpaRepository<User, Integer>, JpaSpecificationExecutor<User> {    Optional<User> findById(UUID id);}

Primeiro, configuramos o h2db. Criamos um arquivo chamado application.yaml em test -> resources:

spring:  application:    name: Spring Boot Rest API  datasource:    type: com.zaxxer.hikari.HikariDataSource    url: "jdbc:h2:mem:test-api;INIT=CREATE SCHEMA IF NOT EXISTS dbo\\;CREATE SCHEMA IF NOT EXISTS definitions;DATABASE_TO_UPPER=false;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=false;MODE=MSSQLServer"    name:    password:    username:    initialization-mode: never    hikari:      schema: dbo  jpa:    database: H2    database-platform: org.hibernate.dialect.H2Dialect    show-sql: true    hibernate:      ddl-auto: create-drop  test:    database:      replace: none

Em seguida, escrevemos o primeiro teste básico para nosso repositório: salvar um usuário e recuperá-lo:

@RunWith(SpringRunner.class)@DataJpaTestpublic class UserRepositoryTest {    @Autowired    TestEntityManager entityManager;    @Autowired    UserRepository sut;    @Test    public void it_should_save_user() {        User user = new User();        user.setName("test user");        user = entityManager.persistAndFlush(user);        assertThat(sut.findById(user.getId()).get()).isEqualTo(user);    }}

Quando executamos veremos algumas saídas no console, e nosso teste também passa:

Agora, vamos adicionar outro método ao nosso repositório para buscar um usuário através do seu e-mail:

Optional<User> findByEmail(String email);

Escrevemos, por fim, outro teste:

@Testpublic void it_should_find_user_byEmail() {    User user = new User();    user.setEmail("testmail@test.com");    user = entityManager.persistAndFlush(user);    assertThat(sut.findByEmail(user.getEmail()).get()).isEqualTo(user);}

Quando damos uma olhada no console depois de executar o teste, vemos o SQL gerado pelo hibernate:

SELECT user0_.id AS id1_1_,user0_.age AS age2_1_,user0_.email AS email3_1_,user0_.name AS name4_1_FROM user user0_WHERE user0_.email=?

Até agora, tudo bem. Cobrimos o básico de testes unitários com o SpringBoot.

Agora, não temos mais desculpas para não escrever testes unitários! Espero que tenha sido claro para você como escrever testes unitários para cada tipo de propósito.

Há pouco tempo, tive a chance de implementar a autorização em JWT para um projeto à parte. Trabalhei anterior com JWT em Ruby on Rails, mas essa foi a primeira vez com o Spring.

Neste artigo, tentarei explicar o que aprendi e apliquei no meu projeto para compartilhar minha experiência e, espero, ajudar algumas pessoas.

Começaremos examinando rapidamente a teoria por trás do JWT e como ele funciona. Em seguida, veremos como implementá-lo em uma aplicação com Spring Boot.

Fundamentos de JWT

JWT, ou JSON Web Tokens (RFC 7519 - texto em inglês), é um padrão que, em grande parte, é usado para a segurança em APIs REST. Embora seja uma tecnologia relativamente nova, ela vem ganhando popularidade rapidamente.

No processo de autorização do JWT, o front-end (o client) primeiramente envia algumas credenciais para se autenticar (nome de usuário e senha, em nosso caso, já que estamos trabalhando com uma autenticação para a web).

O servidor (a aplicação com Spring, em nosso caso), em seguida, verifica essas credenciais. Se elas forem válidas, o servidor gera um JWT e o retorna.

Depois desse passo, o client precisa fornecer esse token no cabeçalho Authorization da solicitação, no formulário “Bearer TOKEN” (Token do portador). O back-end verificará a validade desse token e autorizará ou rejeitará as solicitações. O token também pode armazenar funções de usuário e autorizar as solicitações com base na autoridade fornecida.

Implementação

Vamos ver agora como podemos implementar o login em JWT e o mecanismo de salvamento em uma aplicação em Spring real.

Dependências

Você pode ver abaixo uma lista das dependências do Maven que nosso código de exemplo usa. Observe que as dependências principais, como o Spring Boot e o Hibernate, ainda não estão incluídas nessa captura de tela.

Salvamento de usuários

Começaremos criando os controllers para salvar os usuários com segurança e autenticá-los com base no nome e na senha.

Temos uma entidade modelo chamada User (Usuário). É uma classe de entidade simples que mapeiam para a tabela USER. Você pode usar as propriedades que quiser e necessitar, dependendo de sua aplicação.

Também temos uma classe UserRepository (Repositório de usuários) simples para salvar os usuários. Precisamos sobrescrever o método findByUsername (encontrar por nome de usuário), já que vamos usá-lo na autenticação.

public interface UserRepository extends JpaRepository<User, String>{ 
    User findByUsername(String username); 
}

Jamais devemos armazenar senhas em texto simples no banco de dados, pois muitos usuários costumam usar a mesma senha para vários sites.

Existem muitos algoritmos de hashing diferentes. O mais comumente utilizado é o BCrypt, sendo recomendado para um hashing seguro. Confira este artigo (em inglês) para obter mais informações sobre o tópico.

Para fazer o hashing de uma senha, definiremos um bean do BCrypt em @SpringBootApplication e faremos a anotação da classe principal, como vemos abaixo:

@Bean public BCryptPasswordEncoder bCryptPasswordEncoder() {
    return new BCryptPasswordEncoder(); 
}

Chamaremos os métodos nesse bean quando precisarmos fazer o hashing de uma senha.

Também precisaremos de um UserController para salvar os usuários. Criamos o controller, fazemos a anotação com @RestController e definimos o mapeamento correspondente.

Em nossa aplicação, salvamos o usuário com base em um objeto DTO passado para o front-end. Também é possível passar um objeto User em @RequestBody.

Depois de passarmos o objeto DTO, criptografamos o campo da senha usando o bean do BCrypt que criamos anteriormente. Também é possível fazer isso no controller, mas é uma prática recomendada colocar essa lógica na classe do serviço.

@Transactional(rollbackFor = Exception.class) 
public String saveDto(UserDto userDto) { 
    userDto.setPassword(bCryptPasswordEncoder
           .encode(userDto.getPassword())); 
    return save(new User(userDto)).getId(); 
}

Filtro de autenticação

Precisamos da autenticação para garantir que o usuário seja realmente quem ele diz que é. Usaremos o par clássico de nome de usuário/senha para realizar isso.

Estes são os passos para implementar a autenticação:

1. Criar nosso Authentication Filter (filtro de autenticação), que é uma extensão de UsernamePasswordAuthenticationFilter
2. Criar uma classe de configuração de segurança, que é uma extensão de WebSecurityConfigurerAdapter e aplicar o filtro

Este é o código para o nosso Authentication Filter – como você já deve saber, os filtros são a base do Spring Security.

Ver o JWTAuthenticationFilter.java, hospedado com ❤ pelo GitHub

Vamos analisar esse código passo a passo.

Essa classe é a extensão de UsernamePasswordAuthenticationFilter, que é a classe padrão para a autenticação de senha no Spring Security. Estendemos essa classe para definir nossa lógica de autenticação personalizada.

Fazemos uma chamada para o método setFilterProcessesUrl em nosso construtor. Esse método define o URL de login padrão para o parâmetro fornecido.

Se removermos essa linha, o Spring Security cria o endpoint "/login" por padrão. Ele define o endpoint de login por nós, motivo pelo qual não definimos um endpoint de login em nosso controller explicitamente.

Depois dessa linha, nosso endpoint de login será /api/services/controller/user/login. Você pode usar essa função para se manter consistente com seus endpoints.

Sobrescrevemos os métodos attemptAuthentication esuccessfulAuthentication da classe UsernameAuthenticationFilter.

A função attemptAuthentication é executada quando o usuário tentar fazer o login em nossa aplicação. Ela lê as credenciais, cria um POJO de usuário para eles e verifica as credenciais para a autenticação.

Passamos o nome de usuário, a senha e uma lista vazia. A lista vazia representa as autoridades (funções) e a deixamos assim, já que ainda não temos funções em nossa aplicação.

Se a autenticação tiver sucesso, o método successfulAuthentication é executado. Os parâmetros desse método são passados pelo Spring Security internamente.

O método attemptAuthentication retorna um objeto Authentication que contém as autoridades que passamos ao tentar.

Queremos retornar um token para o usuário após o sucesso da autenticação, por isso criamos o  token usando o nome do usuário, o segredo (secret, em inglês) e a data de validade (expiration date, em inglês). Precisamos definir SECRET e EXPIRATION_DATE agora.

Ver o SecurityConstants.java, hospedado com ❤ pelo GitHub

Criamos uma classe para que ela seja um contêiner para as nossas constantes. Você pode definir o segredo de modo que ele seja o que você quiser, mas a prática recomendada é tornar a chave do segredo tão grande quanto o seu hash. Usamos o algoritmo HS256 neste exemplo. Por isso, nosso chave de segredo é de 256 bits/32 caracteres.

O tempo de validade é definido como sendo de 15 minutos, pois é a prática recomendada contra ataques de força bruta contra a chave do segredo. O tempo é em milissegundos.

Preparamos nosso filtro de autenticação, mas ele ainda não está ativo. Também precisamos de um filtro de autorização. Em seguida, aplicaremos os dois por meio de uma classe de configuração.

Este filtro verificará a existência e a validade do token de acesso no cabeçalho Authorization. Especificaremos quais endpoints estarão sujeitos a esse filtro em nossa classe de configuração.

Filtro de autorização

Ver o JWTAuthorizationFilter.java, hospedado com ❤ pelo GitHub

O método doFilterInternal intercepta as solicitações e verifica o cabeçalho Authorization. Se o cabeçalho não estiver presente ou não iniciar com "BEARER" (portador), ele segue com a cadeia de filtros.

Se o cabeçalhos estiver presente, o método getAuthentication é invocado. getAuthentication verifica o JWT e, se o token for válido, ele retorna um token de acesso que o Spring usará internamente.

Este novo token, então, é salve em SecurityContext (contexto de segurança). Você também pode passar Authorities por esse token se precisar de autorização baseada em funções.

Nossos filtros estão prontos. Agora, precisamos colocá-los em ação com a ajuda de uma classe de configuração.

Configuração

Ver o WebSecurity.java, hospedado com ❤ pelo GitHub

Anotamos essa classe com @EnableWebSecurity e estendemos WebSecurityConfigureAdapter para que implemente nossa lógica de segurança personalizada.

Ativamos automaticamente (auto-wire) o bean do BCrypt que definimos anteriormente. Também ativamos automaticamente UserDetailsService para que encontre a conta do usuário.

O método mais importante é aquele que aceita um objeto HttpSecurity. Aqui, especificamos os endpoints e filtros seguros que queremos aplicar. Configuramos o CORS e, em seguida, permitimos todas as solicitações de post ao nosso URL de entrada, que definimos na classe das constantes.

É possível adicionar outros ant matchers para filtrar com base em padrões de URL e funções. Você pode conferir esta pergunta do StackOverflow (em inglês) para ver exemplos relacionados a isso. O outro método configura o AuthenticationManager (gerenciador de autenticação) para que use nosso objeto de codificação (encoder) como seu codificador de senhas enquanto verifica as credenciais.

Testes

Vamos enviar algumas solicitações para testar se está funcionando corretamente.

Aqui, enviamos uma solicitação GET para acessar um recurso protegido. Nosso servidor responde com um código 403. Esse é o comportamento esperado, pois não fornecemos um token no cabeçalho. Vamos, agora, criar um usuário:

Para criar um usuário, enviamos uma solicitação de post com nossos dados do User DTO. Com esse usuário, faremos o login e obteremos um token de acesso.

Ótimo! Temos o token. Depois disso, usaremos esse token para acessar os recursos protegidos.

Fornecemos o token no cabeçalho Authorization e agora temos permissão de acesso ao nosso endpoint protegido.

Conclusão

Neste tutorial, examinamos passo a passo a implementação da autenticação de senha e da autorização com o JWT no Spring. Também aprendemos como salvar um usuário com segurança.

Obrigado pela leitura – espero que tenha sido útil para você. Se estiver interessado em ler mais conteúdo a respeito do assunto, fique à vontade para se inscrever no blog do autor: https://erinc.io (em inglês). 🙂