DEV Community: Igor Rudel

Dica Java: Actuator #011

Igor Rudel — Fri, 07 Nov 2025 21:36:09 +0000

Nem todos sabem, mas além de proporcionar endpoints como o de coleta de métricas e verificação da saúde da aplicação, o Actuator do Spring possui outros endpoints extremamente úteis.

E nesse post eu gostaria de destacar dois deles: caches e o loggers!

O caches permite:

visualizar informações das caches da aplicação
remover/deletar alguma cache que seja necessária

O loggers permite:

visualizar as configurações de logs
modificar o nível de log de uma classe ou de um pacote

Ambos merecem muito destaque por permitirem a interação com a aplicação em tempo de execução, ou seja, limpar uma cache ou modificar o nível de log sem precisar reiniciá-la!

Até a próxima! :D

Swagger: Resumindo minha visão

Igor Rudel — Mon, 27 Oct 2025 20:04:06 +0000

O Swagger é uma ferramenta voltada principalmente para desenvolvedores. Assim como o motor de um carro, ele exige conhecimento técnico para ser compreendido e mantido. Quando há necessidade de verificar ou ajustar o motor, não se consulta qualquer pessoa — leva-se o carro a um mecânico, que, em tese, sabe o que está fazendo. O mesmo princípio se aplica ao Swagger: ele deve ser utilizado por quem entende da estrutura e funcionamento da API.

Documentar excessivamente no Swagger, incluindo até o que é óbvio, pode gerar ruído. Quando tudo é documentado indiscriminadamente, o que realmente importa pode se perder no meio de tanta informação. Isso compromete a utilidade da documentação, tornando difícil identificar o que é relevante e o que não é.

Portanto, é essencial encontrar um equilíbrio: documentar o necessário, com clareza e objetividade, para que a documentação seja útil e mantenha seu propósito técnico.

Dica Java: Variáveis de Ambiente #010

Igor Rudel — Mon, 01 Sep 2025 23:00:28 +0000

Aposto que você já fez a definição de properties dos seus projetos Spring como no exemplo abaixo:

application.my-variable=${MY_VARIABLE:haha}

spring.application.name=env-variables-ex

Temos uma propriedade customizada e uma default do Spring.

A customizada com um ternário: se for informada uma variável de ambiente, se não um valor default.

A default com valor fixo.

E se eu te contar que não é necessário definir properties com ternários...

E que é possível sobreescrever os valores até das que não possuem o ternário...

O Spring prevê sobreescrita de valores de propriedades seguindo um padrão MUITO simples!

Basta informar como Variáveis de Ambiente o nome da propertie todo maíusculo ou minúsculo e substituir pontos e hífens por underline!

Por exemplo:

APPLICATION_MY_VARIABLE=hiihi;server_port=8081

E também funciona em propriedades não declaradas explícitamente nos arquivos .properties (ou .yml)!

No IntelliJ:

Dica Java: Memorized Supplier #009

Igor Rudel — Wed, 13 Aug 2025 20:34:47 +0000

Para compartilhar essa dica, imagine que precisamos criar um registro militar para uma pessoa. Para isso, buscamos dados em três repositórios distintos:

private PersonRepository repository;
private PersonDetailsRepository detailsRepository;
private MilitaryRegistrationRepository militaryRegistrationRepository;

public void createMilitaryRegistration(final UUID personId) {
    final var person = repository.findById(personId)
        .orElseThrow(); // NotFoundException
    // Validação 1: idade mínima
    // Utiliza: person.birthdate()

    final var details = detailsRepository.findById(personId)
        .orElseThrow(); // NotFoundException
    // Validação 2: nacionalidade brasileira
    // Utiliza: details.brazilian()

    // Validação 3: verificar se já existe registro
    // Utiliza: militaryRegistrationRepository.exists(...)

    militaryRegistrationRepository.save(
       new MilitaryRegistration(
           personId,
           "CODE",
           details.placeOfBirth() // reutilização
       )
    );
}

Esse código é funcional, mas mistura responsabilidades: validações e lógica de criação estão acopladas.

Em sistemas maiores, isso pode se tornar um problema.

Uma abordagem comum é extrair as validações para uma classe dedicada:

public class MilitaryRegistrationValidator {

    private PersonDetailsRepository detailsRepository;

    public void validate(final Person person) {
        // Validação 1: idade mínima
        // Utiliza: person.birthdate()

        final var details = detailsRepository.findById(person.id())
            .orElseThrow(); // NotFoundException

        // Validação 2: nacionalidade brasileira
        // Utiliza: details.brazilian()

        // Validação 3: verificar se já existe registro
        // Utiliza: militaryRegistrationRepository.exists(...)
    }
}

E então injetar o validador no método principal:

public void createMilitaryRegistration(final UUID personId) {
    final var person = repository.findById(personId)
        .orElseThrow(); // NotFoundException

    validator.validate(person);

    final var details = detailsRepository.findById(person.id())
        .orElseThrow(); // NotFoundException

    militaryRegistrationRepository.save(
        new MilitaryRegistration(
            personId,
            "CODE",
            details.placeOfBirth() // reutilização
        )
    );
}

Mas aqui surgem alguns problemas:

O detailsRepository precisa ser injetado em dois lugares.

O método findById é chamado duas vezes para o mesmo dado.

Se a idade estiver incorreta, a consulta aos detalhes nem deveria acontecer.

A solução: Suppliers Memorizados!

Com uma simples classe utilitária, conseguimos transformar qualquer lógica de fornecimento de dados — seja uma consulta ao banco, uma chamada a API, ou até mesmo um cálculo pesado — em algo que será executado apenas uma vez, e cujo resultado poderá ser reutilizado em diferentes partes do código.

public class MemorizedSupplier<T> implements Supplier<T> {

    private final Supplier<T> supplier;
    private T value;

    public MemorizedSupplier(final Supplier<T> supplier) {
        this.supplier = supplier;
    }

    @Override
    public T get() {
        return Optional.ofNullable(value)
            .orElseGet(() -> {
                value = supplier.get();
                return value;
            });
    }
}

Assim, o validador poderia receber um Supplier como argumento:

public class MilitaryRegistrationValidator {

    public void validate(final Person person,
                         final Supplier<PersonDetails> detailsSupplier) {
        // Validação 1: idade mínima
        // Utiliza: person.birthdate()

        final var details = detailsSupplier.get();

        // Validação 2: nacionalidade brasileira
        // Utiliza: details.brazilian()

        // Validação 3: verificar se já existe registro
        // Utiliza: militaryRegistrationRepository.exists(...)
    }
}

E o método principal ficaria assim:

public void createMilitaryRegistration(final UUID personId) {
    final var person = repository.findById(personId)
        .orElseThrow(); // NotFoundException

    final var detailsSupplier = new MemorizedSupplier<>(
        () -> detailsRepository.findById(person.id()).orElseThrow()
    );

    validator.validate(person, detailsSupplier);

    militaryRegistrationRepository.save(
        new MilitaryRegistration(
            personId,
            "CODE",
            detailsSupplier.get().placeOfBirth() // reutilização
        )
    );
}

Gerando os seguintes benefícios:

Eficiência: a consulta ao banco é feita apenas uma vez.

Baixo acoplamento: o repositório é usado em um único lugar.

Reutilização: o mesmo dado pode ser acessado em diferentes partes do código sem reconsultar.

Flexibilidade: o padrão pode ser aplicado em diversos contextos.

Separar responsabilidades é essencial, mas não precisa vir com custo de desempenho ou complexidade. Com Suppliers memorizados, conseguimos manter o código limpo, eficiente e alinhado com boas práticas.

OBS: a ideia apresentada neste artigo não é uma criação original minha, mas sim uma aplicação prática de um conceito funcional bem conhecido: memoization.

LGPD no Código: Evite Armadilhas, Siga Dicas!

Igor Rudel — Mon, 16 Jun 2025 22:10:29 +0000

A LGPD trouxe para o mundo dos DEV's uma série de desafios ao lidar com dados sensíveis. Entre as perguntas mais comuns estão:

Como armazenar esses dados?
Como trafegá-los com segurança?
Como exibi-los sem expor informações?
Quais recursos interagem com esses dados?

Nem sempre existe uma solução única para todos os casos, mas o interessante é que quase todos os recursos e frameworks oferecem formas de lidar com esses desafios de maneira transparente e eficaz.

Armazenamento seguro

No que diz respeito ao armazenamento, bancos relacionais como o MySQL oferecem funções nativas de criptografia, como AES_ENCRYPT e AES_DECRYPT. Integrá-las em aplicações Spring Boot é simples, utilizando anotações como:

@Column
@ColumnTransformer

Se preferir não depender das funções do banco, é possível criptografar e descriptografar os dados com Java puro (java.security) e anotações, usando:

@Convert
@Converter

Comunicação entre serviços

No contexto de microserviços, a comunicação geralmente ocorre via HTTP (REST) ou mensageria (RabbitMQ, Kafka, etc.).

REST: por usar o protocolo HTTP, é possível aplicar SSL/TLS, garantindo a segurança na troca de informações.
Mensageria: além de conexões seguras (TLS, mTLS), é possível criptografar os payloads. No RabbitMQ com Spring, basta adicionar MessageConverter's ao produzir e consumir mensagens.

Cuidados com logs

O Logback, framework padrão de logs no Spring, permite configurar filtros e máscaras para evitar a exposição de dados sensíveis — tudo isso sem alterar uma linha do código da aplicação.

O segredo está nos frameworks

Apesar dos desafios, sempre há formas de atender aos requisitos da LGPD sem impactar diretamente o código da aplicação. A maioria dos frameworks modernos oferece recursos prontos para isso, geralmente baseados no padrão de projeto Interceptor, que permite interceptar ações e manipular informações de forma transparente.

Dicas finais

Em aplicações, o tratamento de dados sensíveis geralmente ocorre nas entradas e saídas (leitura e escrita), nunca no meio do processo;
Requisitos não funcionais, como segurança e privacidade, podem (e devem) ser atendidos sem interferir bruscamente nos algoritmos da aplicação;
Conhecer bem os frameworks e suas ferramentas é o que faz a diferença.

Segue link no GitHub com alguns exemplos: https://github.com/oigorrudel/lgpd-examples

Dica Java: @ParameterizedTest #008

Igor Rudel — Mon, 28 Apr 2025 21:03:34 +0000

Essa é mais uma dica de Testes Unitários!

Com mais algumas dicas ~escondidas~!

Vamos a um exemplo simples de um endpoint POST com body e algumas validações:

@RestController
@RequestMapping("v1/persons")
public class PersonController {

    @PostMapping
    @ResponseStatus(HttpStatus.CREATED)
    public void create(@RequestBody @Valid final PersonBody body) {
        //impl
    }

    @With
    @Builder
    public record PersonBody(@NotBlank @Size(max = 10) String name,
                             @NotNull @Past LocalDate birthdate) {
    }
}

Os testes básicos válidos para esse endpoint são:

o de sucesso, com todos os campos válidos
os de erro, com todas as possibilidades de campos inválidos

Em uma contagem rápida, seria necessário UM de sucesso (CREATED) e cerca de SETE de erro (BAD_REQUEST).

O de sucesso é simples:

@WebMvcTest(PersonController.class)
class PersonControllerTest {

    private static final String URL = "/v1/persons";

    @Autowired
    private MockMvc mockMvc;

    @Autowired
    private ObjectMapper objectMapper;

    @Nested
    class WhenPost {

        private static PersonBody validBody;

        static {
            validBody = PersonBody.builder()
                .name("Igor")
                .birthdate(LocalDate.now().minusDays(1))
                .build();
        }

        @Test
        @SneakyThrows
        void shouldReturnCreated() {
            mockMvc.perform(
                post(URL)
                    .contentType(MediaType.APPLICATION_JSON)
                    .content(objectMapper.writeValueAsString(validBody))
            ).andExpect(status().isCreated());
        }
    }
}

Se desejar testar o body/contrato esperado também é possível:

.andExpect(jsonPath("$.<campo>").value(<expected>))

Porém o foco aqui são os testes de Bad Request (400).

Seria necessário criar UM método para cada @Test e possibilidade de erro do payload enviado:

@Test
@SneakyThrows
void shouldReturnBadRequestBecauseNameIsNull() {
    mockMvc.perform(
        post(URL)
            .contentType(MediaType.APPLICATION_JSON)
            .content(
                objectMapper.writeValueAsString(validBody.withName(null))
            )
    ).andExpect(status().isBadRequest());
}

Se tornaria maçante criar as SETE possibilidades de erros (isso que é um body simples, com apenas 2 campos, imagine payloads mais complexos).

E aqui vai uma solução muito interessante: @ParameterizedTest !

@ParameterizedTest
@MethodSource("badBodies")
@SneakyThrows
void shouldReturnBadRequest(final PersonBody body) {
    mockMvc.perform(
        post(URL)
            .contentType(MediaType.APPLICATION_JSON)
            .content(objectMapper.writeValueAsString(body))
    ).andExpect(status().isBadRequest());
}

static Stream<Arguments> badBodies() {
    return Stream.of(
        Arguments.of(validBody.withName(null)),
        Arguments.of(validBody.withName("")),
        Arguments.of(validBody.withName(" ")),
        Arguments.of(validBody.withName("112233445566")),
        Arguments.of(validBody.withBirthdate(null)),
        Arguments.of(validBody.withBirthdate(LocalDate.now())),
        Arguments.of(validBody.withBirthdate(LocalDate.now().plusDays(1)))
        );
    }
}

Para testes com MÚLTIPLAS situações que devem ter o MESMO resultado os testes parametrizados são perfeitos! Para testes em endpoints que possuam validações o @ParameterizedTest serve como uma luva!

Podem notar que utilizei o @MethodSource para alimentar o argumento do teste, existem outras formas de prover o argumento (pacote: org.junit.jupiter.params.provider).

"Aaaah, além do 400 eu quero testar a mensagem do erro, se é a correta para aquele campo ou não." Essa dica será em outro post!

Dica Java: Organize os testes unitários! #007

Igor Rudel — Fri, 25 Apr 2025 21:22:11 +0000

Essa é uma dica de organização em testes unitários (utilizando JUnit).

Nos casos onde devem ser feitos os testes unitários em classes que possuam mais de um método public e/ou protected como no exemplo abaixo:

@Service
private class PersonService {

    public Person getById(final UUID id) {
    //impl
    }

    public List<Person> getAll(final Optional filters) {
    //impl
    }
}

É interessante dividir os testes de cada método por classes aninhadas e anotadas com @Nested e algum padrão de nomenclatura para essas classes, no caso abaixo com prefixo When e a nomenclatura do método como sufixo:

@ExtendWith(MockitoExtension.class)
class ExampleServiceTest {

    @InjectMocks
    private ExampleService service;

    @Nested
    class WhenGetById {

        @Test
        void shouldDoesNotThrow() {
            final var result = service.getById(UUID.randomUUID());
            //restante do teste
        }
    }

    @Nested
    class WhenGetAll {

        @Test
        void shouldDoesNotThrow() {
            final var result = service.getAll(Optional.empty());
            //restante do teste
        }
    }
}

Em casos onde há muitos cenários de teste para o mesmo método (normalmente muitas situações com estados de objetos diferentes) é interessante refinar em mais classes aninhadas e algum outro prefixo como por exemplo With.

@Nested
class WhenGetAll {

    @Nested
    class WithFilter {

        @Test
        void shouldDoesNotThrow() {
            final var result = service.getAll(Optional.ofNullable(null));
            //restante do teste
        }
    }

    @Nested
    class WithoutFilter {

        @Test
        void shouldDoesNotThrow() {
            final var result = service.getAll(Optional.empty());
            //restante do teste
        }
    }
}

Além de mais organizado os testes, visualmente em sua IDE (ao menos no IntelliJ) também ficará organizado:

Lembrando que testes unitários quando estão muito complexos para se fazer/construir, é bem possível (e provável) que hajam melhorias na organização do próprio código que auxiliarão na manutenção, leitura e construção dos testes unitários.

Dica Java: Quando preciso testar exceções? #006

Igor Rudel — Thu, 24 Apr 2025 14:34:41 +0000

Em testes unitários em Java, com JUnit, existem apenas 2 cenários que necessitam testar exceções:

try-catch's explícitos

disparo de exceções explícitas

Por exemplo nos dois métodos com os cenários abaixo:

@Service
@RequiredArgsConstructor
public class ExampleService {

    private final Repo repo;
    private final Integrator integrator;

    public Person getById(final UUID id) {
        return repo.findById(id)
            .orElseThrow(() -> new IllegalArgumentException("person.not.found")); //possivelmente customizada
    }

    public Person create(final Person person) {
        try {
            return integrator.create(person);
        } catch (final Exception exception) {
            //lógica do tratamento da exceção

            throw exception;
        }
    }
}

Os testes de ambos os cenários seria:

@ExtendWith(MockitoExtension.class)
class ExampleServiceTest {

    @InjectMocks
    private ExampleService service;

    @Mock
    private Repo repo;

    @Mock
    private Integrator integrator;

    @Nested
    class WhenGetById {

        @Test
        void shouldThrow() {
            final var id = UUID.randomUUID();

            when(repo.findById(id))
                .thenReturn(Optional.empty());

            final var exception = assertThrows(
                IllegalArgumentException.class, () -> service.getById(id)
            );

            assertEquals("person.not.found", exception.getMessage());
        }
    }

    @Nested
    class WhenCreate {

        @Test
        void shouldThrow() {
            final var person = new Person("João");

            when(integrator.create(person))
                .thenThrow(IllegalArgumentException.class);

            assertThatThrownBy(() -> service.create(person))
                .isInstanceOf(IllegalArgumentException.class);
        }
    }
}

E o teste da exceção termina aqui, as classes que irão fazer a injeção da dependência da service não devem simular/mockar exceções no uso desses métodos (a não ser que haja try/catch explícito).

Simular/mockar exceções em outros cenários é ineficaz e infértil. Por exemplo o método:

public Person update(final Person person) {
    return integrator.update(person);
}

E fazer esse teste:

@Nested
class WhenUpdate {

    @Test
    void shouldThrow() {
        final var person = new Person("João");

        when(integrator.update(person))
            .thenThrow(IllegalArgumentException.class);

        assertThatThrownBy(() -> service.update(person))
            .isInstanceOf(IllegalArgumentException.class);
    }
}

Sucesso no teste, porém é inútil. Pode-se fazer um paralelo com ter que testar NullPointerException em cada get ou uso de objeto.

Dica extra: quando usar o assertThatThrownBy ou assertThrows ?
assertThatThrownBy quando precisa testar apenas coisas básicas da exceção (mensagem, tipo, etc...) e assertThrows quando precisa testar estados e/ou comportamentos de alguma exceção customizada.

Em aplicações Spring Boot que possuem camada WEB (normalmente Rest) é normal termos uma camada Handler e/ou @ControllerAdvice onde tem o tratamento global de exceções. O teste que é realmente efetivo para essa camada é simular uma controller e mockar o disparo de uma exceção em alguma camada (service ou mapper) para que o tratamento global seja acionado e resultar no JSON customizado de erros esperado (papo para outro post).

Dica Java: Use o ciclo de vida do UT! #005

Igor Rudel — Wed, 16 Apr 2025 20:53:33 +0000

É muito importante conhecer o ciclo de vida dos testes unitários no desenvolvimento de serviços com Spring Boot.

A biblioteca spring-boot-starter-test do Spring traz consigo atualmente todos os recursos (ou quase todos) necessários para testes com JUnit na sua última versão.

Nos testes de componentes/beans de um projeto, é comum o uso das anotações @ExtendWith(MockitoExtension.class), @InjectMocks e @Mock.

@ExtendWith(MockitoExtension.class)
class TestTest {

    @InjectMocks
    private Test test;

    @Mock
    private LalaService service;

    //testes abaixo
}

E é comum nos testes termos reaproveitamento de estados de objetos nos vários cenários em que os estados se repetem ou que modifiquem parcialmente.

@ExtendWith(MockitoExtension.class)
class TestTest {

    @InjectMocks
    private Test test;

    @Mock
    private LalaService service;

    @Test
    void shouldDoesNotThrow() {
        final var person = buildValidPerson();
        //restante do teste
    }

    @Test
    void shouldThrow() {
        final var person = buildValidPerson();
        //restante do teste
    }

    static Person buildValidPerson() {
        return new Person("João");
    }
}

Evite usar métodos estáticos para a geração desses objetos reaproveitáveis. Utilize o @BeforeEach (que executa antes de cada teste unitário) e atributos nos testes que armazenem estes valores. Assim terá o mesmo resultado, mas utilizando o ciclo de vida do teste unitário da melhor forma.

@ExtendWith(MockitoExtension.class)
class TestTest {

    @InjectMocks
    private Test test;

    @Mock
    private LalaService service;

    private Person person;

    @BeforeEach
    void setup() {
        person = new Person("João");
    }

    @Test
    void shouldDoesNotThrow() {
        //restante do teste
    }

    @Test
    void shouldThrow() {
        //restante do teste
    }
}

Uma das exceções de uso de métodos estáticos gerando massas são para testes parametrizados (@ParameterizedTest e @MethodSource). E mesmo assim, são para conjunto de objetos de estados diferentes, não se aplica a reaproveitamento de estados.

Além do @BeforeEach existe também o @AfterEach que, como o próprio nome diz, é após cada teste.

Utilizar o @BeforeEach faz com que o teste unitário, seja ele único ou múltiplo, obedeça o ciclo de vida default (que é por método, é possível configurar por classe, mas isso é papo para outro post) do JUnit.

Dica Java: Evite poluir as entidades #004

Igor Rudel — Mon, 14 Apr 2025 23:17:44 +0000

As anotações do JPA (Java Persistence API) existem a milênios! Com a evolução dos frameworks, principalmente do Spring, e do próprio Java muitos recursos evoluíram junto.

Por exemplo, em antigas versões para definir uma coluna em uma entidade (@Entity) era obrigatório anotar o atributo com @Column, se o padrão de colunas do banco fossem undercase era ainda necessário definir o nome da coluna.

@Data
@Entity
public class Person {

    @Id
    //outros atributos

    @Column(name = "last_name")
    private String lastName;
}

Com o tempo houve uma evolução, já que por padrão as colunas eram undercase, apenas a anotação bastava para o de->para entre os padrões undercase e camelCase.

@Data
@Entity
public class Person {

    @Id
    //outros atributos

    @Column
    private String lastName;
}

Atualmente basta adicionar o @Entity e todos os atributos são identificados automaticamente como referências a colunas, sendo obrigatório apenas a definição do @Id.

@Data
@Entity
public class Person {

    @Id
    //outros atributos

    private String lastName;
}

Então torná-se implícito a definição das colunas, se fazendo desnecessário a anotação explícita.

Isso faz a entidade ficar clean.

Um adendo de dica, é na necessidade de anotar um atributo com @Column porém evitar ao máximo a definição dos argumentos na anotação, como no exemplo:

@Column(nullable = false)

Costumo orientar que essa responsabilidade não é da API (do mapeamento), essa responsabilidade é TOTALMENTE do banco de dados, é ele que deve definir tais regras da coluna, pois ele é que tem que garantir a estrutura e integridade dos dados, e NÃO a aplicação, afinal, ele pode ser consumido por outras aplicações, recursos e/ou frameworks. Fazer as definições por exemplo de nullable, insertable, e as demais, é ter a replicação da regra que deveria estar apenas no banco.

Uma boa prática para o desenvolvedor, já que ele não terá essa informação na entidade, é analisar o banco (as tabelas) executando um explain para compreender a estrutura e as regras.

É mais trabalhoso? Talvez, mas é o que acredito ser o mais correto pensando nas responsabilidades dos recursos.

Spring Boot 3 + Hibernate: Logando undefined/unknown

Igor Rudel — Fri, 04 Apr 2025 20:18:36 +0000

A partir de uma certa versão do Spring Boot 3, utilizando JPA o Hibernate adicionou os seguintes log's:

org.hibernate.orm.connections.pooling    : HHH10001005: Database info:
    Database JDBC URL [Connecting through datasource 'HikariDataSource (HikariPool-1)']
    Database driver: undefined/unknown
    Database version: 2.3.232
    Autocommit mode: undefined/unknown
    Isolation level: undefined/unknown
    Minimum pool size: undefined/unknown
    Maximum pool size: undefined/unknown

Para que essas informações venham populadas é necessário definir 2 propriedades:

spring.jpa.hibernate.ddl-auto
spring.jpa.properties.hibernate.connection.url

A spring.jpa.properties.hibernate.connection.url populada:

spring.jpa.properties.hibernate.connection.url=${spring.datasource.url}

O resultado será parecido com este:

org.hibernate.orm.connections.pooling    : HHH10001005: Database info:
    Database JDBC URL [jdbc:h2:mem:db;DB_CLOSE_DELAY=-1;INIT=CREATE SCHEMA test\;]
    Database driver: org.h2.Driver
    Database version: 2.3.232
    Autocommit mode: false
    Isolation level: undefined/unknown
    Minimum pool size: 1
    Maximum pool size: 20

Outras 3 propriedades que alteram as configurações da conexão/datasource:

spring.jpa.properties.hibernate.connection.autocommit
spring.jpa.properties.hibernate.connection.isolation
spring.jpa.properties.hibernate.connection.pool_size

Na propriedade spring.jpa.properties.hibernate.connection.isolation os possíveis valores são: TRANSACTION_READ_UNCOMMITTED, TRANSACTION_READ_COMMITTED, TRANSACTION_REPEATABLE_READ ou TRANSACTION_SERIALIZABLE

Dica Java: Métodos estáticos não! #003

Igor Rudel — Tue, 25 Mar 2025 20:32:29 +0000

Essa dica: é muito importante para quem faz testes unitários!

Imagine uma service com 2 métodos que possuem a mesma validação (IF) como abaixo:

@Service
@RequiredArgsConstructor
public class PersonService {

    private static final int ADULT_AGE = 18;

    public void createAdult(final PersonDomain person) {
        if (ADULT_AGE > Period.between(person.birthdate(), LocalDate.now()).getYears()) {
            throw new UnsupportedOperationException("person.is.not.adult");
        }
    }

    public void registerCNH(final PersonDomain person) {
        if (ADULT_AGE > Period.between(person.birthdate(), LocalDate.now()).getYears()) {
            throw new UnsupportedOperationException("person.is.not.adult");
        }
    }
}

Há uma replicação de código: IF + exceção.

Se o projeto tivesse testes unitários, para ter a cobertura teria que ser algo como o código abaixo:

@ExtendWith(MockitoExtension.class)
class PersonServiceTest {

    @InjectMocks
    private PersonService service;

    @Nested
    class WhenCreateAdult {

        @Test
        void shouldDoesNotThrow() {
            final var person = new PersonDomain(LocalDate.now().minusYears(18));

            assertDoesNotThrow(() -> service.createAdult(person));
        }

        @Test
        void shouldDoesNotThrow2() {
            final var person = new PersonDomain(LocalDate.now().minusYears(19));

            assertDoesNotThrow(() -> service.createAdult(person));
        }

        @Test
        void shouldThrow() {
            final var person = new PersonDomain(LocalDate.now().minusYears(17));

            assertThatThrownBy(() -> service.createAdult(person))
                .isInstanceOf(UnsupportedOperationException.class)
                .hasMessage("person.is.not.adult");
        }
    }

    @Nested
    class WhenRegisterCNH {

        @Test
        void shouldDoesNotThrow() {
            final var person = new PersonDomain(LocalDate.now().minusYears(18));

            assertDoesNotThrow(() -> service.registerCNH(person));
        }

        @Test
        void shouldDoesNotThrow2() {
            final var person = new PersonDomain(LocalDate.now().minusYears(19));

            assertDoesNotThrow(() -> service.registerCNH(person));
        }

        @Test
        void shouldThrow() {
            final var person = new PersonDomain(LocalDate.now().minusYears(17));

            assertThatThrownBy(() -> service.registerCNH(person))
                .isInstanceOf(UnsupportedOperationException.class)
                .hasMessage("person.is.not.adult");
        }
    }
}

Terá então replicação de código e de teste unitário.

É comum para evitar a replicação de código, separar em outra classe e reaproveitar o mesmo código.

public class PersonValidator {

    private static final int ADULT_AGE = 18;

    public static void verifyAdult(final PersonDomain person) {
        if (ADULT_AGE > Period.between(person.birthdate(), LocalDate.now()).getYears()) {
            throw new UnsupportedOperationException("person.is.not.adult");
        }
    }
}

Na service o código ficaria.

@Service
@RequiredArgsConstructor
public class PersonService {

    public void createAdult(final PersonDomain person) {
        PersonValidator.verifyAdult(person);
    }

    public void registerCNH(final PersonDomain person) {
        PersonValidator.verifyAdult(person);
    }
}

OK, foi resolvido a replicação do IF e do throw, porém o teste unitário ainda está replicado! E por isso é recomendado sempre usar Bean's! Evitar o uso de métodos estáticos e transformar a classe em uma Bean.

@Component
public class PersonValidator {

    private static final int ADULT_AGE = 18;

    public void verifyAdult(final PersonDomain person) {
        if (ADULT_AGE > Period.between(person.birthdate(), LocalDate.now()).getYears()) {
            throw new UnsupportedOperationException("person.is.not.adult");
        }
    }
}

A PersonService com a injeção de dependência da nova Bean.

@Service
@RequiredArgsConstructor
public class PersonService {

    private final PersonValidator validator;

    public void createAdult(final PersonDomain person) {
        validator.verifyAdult(person);
    }

    public void registerCNH(final PersonDomain person) {
        validator.verifyAdult(person);
    }
}

O teste unitário fica único.

@ExtendWith(MockitoExtension.class)
class PersonValidatorTest {

    @InjectMocks
    private PersonValidator validator;

    @Nested
    class WhenVerifyAdult {

        @Test
        void shouldDoesNotThrow() {
            final var person = new PersonDomain(LocalDate.now().minusYears(18));

            assertDoesNotThrow(() -> validator.verifyAdult(person));
        }

        @Test
        void shouldDoesNotThrow2() {
            final var person = new PersonDomain(LocalDate.now().minusYears(19));

            assertDoesNotThrow(() -> validator.verifyAdult(person));
        }

        @Test
        void shouldThrow() {
            final var person = new PersonDomain(LocalDate.now().minusYears(17));

            assertThatThrownBy(() -> validator.verifyAdult(person))
                .isInstanceOf(UnsupportedOperationException.class)
                .hasMessage("person.is.not.adult");
        }
    }
}

E o teste unitário na PersonService torna-se apenas um verify.

@ExtendWith(MockitoExtension.class)
class PersonServiceTest {

    @InjectMocks
    private PersonService service;

    @Mock
    private PersonValidator validator;

    @Nested
    class WhenCreateAdult {

        @Test
        void shouldDoesNotThrow() {
            final var person = new PersonDomain(LocalDate.now());

            assertDoesNotThrow(() -> service.createAdult(person));

            verify(validator).verifyAdult(person);
        }
    }

    @Nested
    class WhenRegisterCNH {

        @Test
        void shouldDoesNotThrow() {
            final var person = new PersonDomain(LocalDate.now());

            assertDoesNotThrow(() -> service.registerCNH(person));

            verify(validator).verifyAdult(person);
        }
    }
}

Obtém-se o mesmo resultado com o mesmo objetivo e ainda mantém boas práticas de código e testes.

No exemplo foi utilizado apenas um método com retorno void e utilizado apenas em dois locais do sistema, porém esse exemplo se aplica a cenários mais complexos onde condicionais ou estados de objetos influenciam e alteram os comportamentos dos componentes do sistema em N locais. Essa dica torna mais fácil, mais eficiente e menos desgastantes os testes unitários.