Forem: Gilson Silva

Hot-Reload de Configurações de Portal Manager via /actuator/refresh no Spring Boot

Gilson Silva — Sat, 18 Oct 2025 02:21:56 +0000

1. Como funciona o `/actuator/refresh`?

O /actuator/refresh recarrega propriedades externas de qualquer origem suportada pelo Spring Cloud (não só ConfigMap). Ou seja, se sua aplicação já busca configs de Portais Managers via PropertySource ou Config Server, o refresh pode funcionar sim para esses valores.

2. Fontes Externas Suportadas

Spring Cloud Config Server (centraliza configs em Git, S3, etc.)
AWS Parameter Store e AWS Secrets Manager (via Spring Cloud AWS)
HashiCorp Vault, Consul, etc.
Qualquer fonte implementada via PropertySource

Resumo: Se o Portal Manager está integrado como um PropertySource do Spring Environment, o /actuator/refresh pode recarregar esses valores.

3. Exemplo: AWS Parameter Store/Secrets Manager

a) Dependências

<!-- Spring Boot Actuator e Cloud -->
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
  <groupId>io.awspring.cloud</groupId>
  <artifactId>spring-cloud-starter-aws-parameter-store-config</artifactId>
</dependency>
<!-- ou -->
<dependency>
  <groupId>io.awspring.cloud</groupId>
  <artifactId>spring-cloud-starter-aws-secrets-manager-config</artifactId>
</dependency>

b) Configuração do application.properties

management.endpoints.web.exposure.include=refresh,health,info
spring.config.import=aws-parameterstore:/ # ou aws-secretsmanager:/

c) Uso no código

@Value("${minha.configuracao.sensivel}")
private String segredo;

d) Processo de atualização

Altere o valor no Portal Manager (ex: AWS Parameter Store).
Chame o endpoint /actuator/refresh na aplicação.
O valor é recarregado sem reiniciar o pod.

4. Observações Importantes

Nem todos os beans/leitura de config reagem automaticamente ao refresh! Use @RefreshScope nas classes/beans que dependem desses valores dinâmicos.

@RefreshScope
@RestController
public class MinhaController {
    @Value("${minha.configuracao.sensivel}")
    private String segredo;
    // ...
}

O /actuator/refresh não recarrega configs de pods alheios. Se você tem múltiplos pods, chame em todos (ou utilize Spring Cloud Bus para broadcast).
Segurança: configure autenticação no endpoint /actuator/refresh!
Para AWS, use as bibliotecas do Spring Cloud AWS.

5. Fluxo Resumido

Integre o Portal Manager à sua aplicação Spring Boot via PropertySource.
Use /actuator/refresh para recarregar configs em tempo real.
Marque beans críticos como @RefreshScope.

Conclusão

Você não precisa usar ConfigMap para usar /actuator/refresh! O segredo é garantir que seu Portal Manager está integrado como fonte de propriedades externas no Spring. Após alterar o valor no portal, basta acionar o refresh.

Simulando um ambiente AWS com LocalStack

Gilson Silva — Wed, 27 Nov 2024 01:03:52 +0000

Se você está desenvolvendo aplicações que utilizam serviços da AWS, mas deseja evitar custos ou a complexidade de configurar recursos diretamente na nuvem, o LocalStack é uma excelente solução. Ele permite simular um ambiente AWS localmente, oferecendo suporte a diversos serviços como S3, Lambda, DynamoDB, entre outros. Neste artigo, vamos explorar como configurar e usar o LocalStack para simular um ambiente AWS.

O que é o LocalStack?

O LocalStack é uma ferramenta que emula serviços da AWS em um ambiente local. Ele é amplamente utilizado para desenvolvimento e testes, permitindo que você crie, configure e interaja com recursos da AWS sem precisar de uma conta ou conexão com a nuvem.

Passo a Passo para Configurar o LocalStack

1. Pré-requisitos

Antes de começar, certifique-se de ter os seguintes itens instalados:

Docker: O LocalStack é executado como um contêiner Docker.
AWS CLI: Para interagir com os serviços simulados.
LocalStack CLI (opcional): Para gerenciar o LocalStack de forma mais eficiente.

2. Instalando o LocalStack

Execute o seguinte comando para iniciar o LocalStack usando Docker:

docker run --rm -it -p 4566:4566 -p 4571:4571 localstack/localstack

Isso iniciará o LocalStack e disponibilizará os serviços na porta 4566.

3. Configurando a AWS CLI

Configure a AWS CLI para apontar para o LocalStack:

aws configure

Access Key ID: test
Secret Access Key: test
Default region: us-east-1
Output format: json

Em seguida, adicione o endpoint do LocalStack ao executar comandos. Por exemplo:

aws s3 ls --endpoint-url=http://localhost:4566

4. Criando Recursos Simulados

Agora você pode criar e interagir com recursos simulados. Por exemplo, para criar um bucket S3:

aws s3api create-bucket --bucket my-local-bucket --endpoint-url=http://localhost:4566

Para listar os buckets:

aws s3api list-buckets --endpoint-url=http://localhost:4566

5. Testando Funções Lambda

Você também pode testar funções Lambda localmente. Primeiro, crie uma função Lambda simulada:

aws lambda create-function \
  --function-name my-function \
  --runtime python3.8 \
  --role arn:aws:iam::123456789012:role/execution_role \
  --handler lambda_function.lambda_handler \
  --code S3Bucket=my-local-bucket,S3Key=lambda-code.zip \
  --endpoint-url=http://localhost:4566

Vantagens do LocalStack

Custo Zero: Evita custos associados ao uso de serviços reais da AWS.
Desenvolvimento Offline: Ideal para ambientes sem conexão com a internet.
Rápida Configuração: Recursos podem ser criados e destruídos rapidamente.
Integração com Ferramentas: Funciona bem com ferramentas como Terraform, AWS CLI e SDKs.

Exemplo de Configuração Completa

Aqui está um exemplo de configuração completa para simular um ambiente AWS com LocalStack:

Dockerfile

FROM public.ecr.aws/docker/library/node:21-slim

RUN npm install -g npm@latest --loglevel=error
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*

WORKDIR /usr/src/app
COPY package*.json ./
RUN npm install --loglevel=error
COPY . .

RUN NODE_OPTIONS=--openssl-legacy-provider REACT_APP_API_URL=http://localhost:4566 SKIP_PREFLIGHT_CHECK=true npm run build --prefix client
RUN mv client/build build
RUN rm -rf client/*
RUN mv build client/

EXPOSE 8080
CMD [ "npm", "start" ]

Buildspec para Testes

version: 0.2
phases:
install:
commands:
- echo Installing Node 21 e npm.....
- curl -fsSL https://rpm.nodesource.com/setup_21.x | sudo bash -
- sudo yum install -y nodejs
build:
commands:
- echo Build iniciado em date
- npm install --loglevel=error
- REACT_APP_API_URL=http://localhost:3001 SKIP_PREFLIGHT_CHECK=true npm run build --prefix client
- echo Rodando testes unitários.....
- npm test
- echo Testes unitários concluídos em date

Conclusão

O LocalStack é uma ferramenta poderosa para simular serviços da AWS localmente, permitindo que desenvolvedores testem e validem suas aplicações sem depender de um ambiente real. Com ele, você pode economizar tempo e dinheiro enquanto mantém a flexibilidade de trabalhar com os serviços da AWS.

Para mais informações, visite o site oficial do LocalStack: https://www.localstack.cloud

📝 Logar de Maneira Sistemática: A Técnica dos 5 W

Gilson Silva — Mon, 14 Oct 2024 23:13:59 +0000

O log é uma prática essencial no desenvolvimento de software, permitindo que desenvolvedores e equipes de operações monitorem, depurem e mantenham sistemas de forma eficiente. No entanto, para que os logs sejam realmente úteis, é importante que sejam feitos de maneira sistemática e organizada. Uma técnica eficaz para isso é o uso dos 5 W: What, Why, Who, Where, When.

1. What (O quê?)
O que está sendo logado?

O primeiro passo para um log eficiente é definir o que será registrado. Isso pode incluir eventos importantes, erros, exceções, mudanças de estado, entre outros. O objetivo é capturar informações que ajudem a entender o comportamento do sistema.

Exemplo:

{
  "event": "user_login",
  "status": "success",
  "user_id": 12345
}

2. Why (Por quê?)
Por que esse evento é importante?

Nem todos os eventos precisam ser logados. É importante entender por que você está registrando determinado evento. Isso ajuda a evitar logs desnecessários e a focar em informações que realmente agregam valor, como erros críticos ou ações que afetam diretamente o funcionamento do sistema.

Exemplo:

Logar tentativas de login falhas pode ajudar a identificar possíveis ataques de força bruta.
Logar mudanças de configuração pode ser útil para auditoria e rastreamento de problemas.

3. Who (Quem?)
Quem realizou a ação?

Identificar quem realizou a ação é crucial para rastrear a origem de eventos. Isso pode ser um usuário, um serviço ou até mesmo um sistema externo. Incluir essa informação nos logs facilita a auditoria e a resolução de problemas.

Exemplo:

{
  "event": "file_upload",
  "user_id": 67890,
  "file_name": "document.pdf"
}

4. Where (Onde?)
Onde o evento ocorreu?

Saber onde o evento ocorreu é importante para identificar o contexto. Isso pode incluir o nome do servidor, o ambiente (produção, desenvolvimento), ou até mesmo a localização geográfica do usuário. Essa informação ajuda a isolar problemas específicos de um ambiente ou região.

Exemplo:

{
  "event": "api_request",
  "endpoint": "/api/v1/orders",
  "server": "prod-server-01"
}

5. When (Quando?)
Quando o evento aconteceu?

Registrar quando o evento ocorreu é fundamental para correlacionar eventos e identificar padrões. A marcação de tempo (timestamp) deve ser precisa e, de preferência, no formato UTC para evitar confusões com fusos horários.

Exemplo:

{
  "event": "payment_processed",
  "timestamp": "2024-10-14T20:30:00Z"
}

Conclusão

Utilizar a técnica dos 5 W para logar de maneira sistemática garante que seus logs sejam mais organizados, úteis e fáceis de interpretar. Isso facilita a identificação de problemas, a auditoria de ações e a manutenção do sistema como um todo. Lembre-se de sempre registrar o que aconteceu, por que é importante, quem realizou a ação, onde ocorreu e quando aconteceu.

Ao aplicar essa técnica, você estará criando logs mais eficientes e que realmente agregam valor ao seu processo de desenvolvimento e operação.

Testes Parametrizados com JUnit 5: Um Exemplo Prático 🚀

Gilson Silva — Wed, 02 Oct 2024 15:38:18 +0000

Os testes parametrizados são uma poderosa funcionalidade do JUnit 5 que permite executar o mesmo teste várias vezes com diferentes conjuntos de dados. Isso é especialmente útil quando você deseja testar um método com várias entradas e garantir que ele se comporte corretamente em todos os cenários.

Neste artigo, vamos explorar como criar testes parametrizados usando o JUnit 5, com base no exemplo de um teste que verifica a criação de um objeto Planet com dados inválidos.

Antes, o que são Testes Parametrizados?

Testes parametrizados permitem que você execute o mesmo teste várias vezes com diferentes argumentos. Em vez de duplicar o código de teste para cada conjunto de dados, você pode fornecer uma lista de argumentos e o JUnit 5 executará o teste para cada um deles.

No JUnit 5, a anotação @ParameterizedTest é usada para indicar que um método de teste deve ser executado várias vezes com diferentes parâmetros. Esses parâmetros podem ser fornecidos de várias maneiras, como por meio de métodos estáticos (@MethodSource), valores enumerados (@EnumSource), ou até mesmo listas de valores (@ValueSource). Em nosso exemplo, iremos utilizar @MethodSource.

Exemplo de Teste SEM Parametrizado

Exemplo de Teste Parametrizado

Vamos considerar o seguinte cenário: temos uma classe Planet que possui três atributos: name, climate e terrain. Queremos garantir que, ao tentar salvar um planeta com dados inválidos (como null ou strings vazias), uma exceção seja lançada.

Aqui está o exemplo de um teste parametrizado que cobre esse cenário:

Explicação do Código:

@ParameterizedTest: Esta anotação indica que o método de teste será executado várias vezes, uma para cada conjunto de dados fornecido.
@MethodSource("providesInvalidPlanets"): Aqui, estamos usando um método estático chamado providesInvalidPlanets para fornecer os argumentos para o teste. Esse método retorna um Stream de argumentos que serão passados para o teste.
@DisplayName: Esta anotação é usada para fornecer uma descrição legível para o teste, o que facilita a leitura dos relatórios de teste.
assertThatThrownBy: Este método, da biblioteca AssertJ, é usado para verificar se uma exceção é lançada ao tentar salvar um planeta com dados inválidos. Estamos esperando que uma RuntimeException seja lançada.

Método de Fornecimento de Dados

O método providesInvalidPlanets é responsável por fornecer os diferentes conjuntos de dados que serão usados no teste. Ele retorna um Stream de Arguments, onde cada Arguments.of representa um conjunto de dados (neste caso, um objeto Planet com valores inválidos).

Explicação do Método:

Stream.of: Estamos criando um Stream de argumentos, onde cada argumento é um objeto Planet com diferentes combinações de valores inválidos (como null ou strings vazias).
Arguments.of: Cada chamada a Arguments.of cria um conjunto de argumentos que será passado para o teste. Neste caso, estamos criando planetas com combinações inválidas de name, climate e terrain.

Vantagens dos Testes Parametrizados

Redução de Código Duplicado: Em vez de escrever vários métodos de teste para cada cenário, você pode usar um único método parametrizado, o que reduz a duplicação de código.
Facilidade de Manutenção: Se você precisar adicionar ou modificar um cenário de teste, basta alterar o método que fornece os dados, sem precisar duplicar o código de teste.
Cobertura Abrangente: Testes parametrizados permitem que você cubra uma ampla gama de cenários com facilidade, garantindo que seu código seja testado em diferentes condições.

Conclusão

Os testes parametrizados são uma ferramenta poderosa no JUnit 5, permitindo que você execute o mesmo teste com diferentes conjuntos de dados de forma eficiente. No exemplo acima, mostramos como testar a criação de um objeto Planet com dados inválidos, garantindo que uma exceção seja lançada em todos os cenários.

Essa abordagem não só melhora a cobertura de testes, mas também torna o código de teste mais limpo e fácil de manter. Se você ainda não está usando testes parametrizados em seus projetos, agora é um ótimo momento para começar!

Testes Subcutâneos - Comparação entre TestRestTemplate e WebTestClient em Testes de Integração 🧑‍💻

Gilson Silva — Tue, 01 Oct 2024 22:39:25 +0000

Ao realizar testes de integração em aplicações Spring Boot, duas abordagens populares para testar endpoints REST são o uso de TestRestTemplate e WebTestClient. Ambas as abordagens têm suas vantagens e desvantagens, e a escolha entre elas depende do contexto e das necessidades do projeto.

Neste artigo, vamos comparar essas duas abordagens com base em dois exemplos de código.

1. Testando com TestRestTemplate

@Test
@DisplayName("Create Planet Return Created")
void createPlanet_ReturnCreated() {
    var sut = restTemplate.postForEntity(URL, PLANET_REQUEST_IT, PlanetResponse.class);

    assertThat(sut.getStatusCode()).isEqualTo(HttpStatus.CREATED);

    assertThat(sut.getBody()).isNotNull();

    assertThat(sut.getBody().name()).isEqualTo(PLANET_REQUEST_IT.name());
    assertThat(sut.getBody().terrain()).isEqualTo(PLANET_REQUEST_IT.terrain());
    assertThat(sut.getBody().climate()).isEqualTo(PLANET_REQUEST_IT.climate());
}

Vantagens do TestRestTemplate:

Simplicidade: O TestRestTemplate é fácil de usar e se integra bem com o Spring Boot. Ele é uma extensão do RestTemplate, o que o torna familiar para desenvolvedores que já utilizam o RestTemplate em suas aplicações.
Testes de Integração Completa: O TestRestTemplate é ideal para testes de integração completos, onde o servidor da aplicação é iniciado em uma porta real (ou aleatória) e as requisições são feitas como se fossem de um cliente externo.
Suporte a Vários Métodos HTTP: Ele oferece suporte a todos os métodos HTTP (GET, POST, PUT, DELETE, etc.) e permite testar a API de forma semelhante a como um cliente real interagiria com ela.

Desvantagens do TestRestTemplate:

Menos Flexível para Testes Reativos: O TestRestTemplate não é ideal para aplicações reativas, como aquelas que utilizam o Spring WebFlux. Ele foi projetado para o paradigma de programação imperativa.
Menos Controle sobre a Resposta: Embora seja possível verificar o status e o corpo da resposta, o TestRestTemplate não oferece tantas opções de verificação e manipulação da resposta quanto o WebTestClient.

2. Testando com WebTestClient

@Test
@DisplayName("Create Planet With WebTestClient Return Created")
void createPlanet_WithWebTestClient_ReturnsCreated() {
    var sut = webTestClient.post().uri(URL).bodyValue(PLANET_REQUEST_IT)
            .exchange().expectStatus().isCreated().expectBody(PlanetResponse.class)
            .returnResult().getResponseBody();

    assertThat(sut).isNotNull();
    assertThat(sut.name()).isEqualTo(PLANET_REQUEST_IT.name());
    assertThat(sut.climate()).isEqualTo(PLANET_REQUEST_IT.climate());
    assertThat(sut.terrain()).isEqualTo(PLANET_REQUEST_IT.terrain());
}

Vantagens do WebTestClient:

Suporte a Aplicações Reativas: O WebTestClient foi projetado para trabalhar com o Spring WebFlux, o que o torna ideal para testar aplicações reativas. Ele suporta fluxos assíncronos e reativos, permitindo testar APIs que utilizam Mono e Flux.
Maior Controle sobre a Resposta: O WebTestClient oferece uma API fluente que permite verificar o status da resposta, o corpo e até mesmo os headers de forma mais detalhada. Isso proporciona maior flexibilidade e controle sobre o que está sendo testado.
Testes Sem Necessidade de Servidor Real: O WebTestClient pode ser usado para testar controladores diretamente, sem a necessidade de iniciar um servidor real. Isso pode acelerar os testes e torná-los mais eficientes.

Desvantagens do WebTestClient:

Curva de Aprendizado: A API do WebTestClient pode ser um pouco mais complexa para desenvolvedores que estão acostumados com o RestTemplate ou TestRestTemplate. A abordagem fluente pode exigir um pouco mais de tempo para se acostumar.
Menos Adequado para Aplicações Imperativas: Embora o WebTestClient possa ser usado em aplicações não reativas, ele é mais adequado para o paradigma reativo. Para aplicações imperativas, o TestRestTemplate pode ser uma escolha mais simples e direta.

Comparação Direta

Característica	TestRestTemplate	WebTestClient
Paradigma	Imperativo	Reativo
Facilidade de Uso	Simples e familiar	API fluente, mais flexível, mas mais complexa
Suporte a WebFlux	Não	Sim
Controle sobre a Resposta	Básico	Avançado
Necessidade de Servidor	Sim	Não
Velocidade dos Testes	Mais lento	Mais rápido

Conclusão

A escolha entre TestRestTemplate e WebTestClient depende do tipo de aplicação que você está desenvolvendo e do nível de controle que você precisa nos seus testes. Se você está trabalhando com uma aplicação imperativa e precisa de testes simples e diretos, o TestRestTemplate pode ser a melhor escolha. No entanto, se você está desenvolvendo uma aplicação reativa ou precisa de mais controle sobre as respostas HTTP, o WebTestClient oferece uma abordagem mais poderosa e flexível.

Ambas as ferramentas são úteis em diferentes contextos, e entender suas diferenças pode ajudar a escolher a abordagem certa para seus testes de integração.

Como Resolver Problemas com jsonPath("$") ao Usar Records no Java ❌😢

Gilson Silva — Tue, 01 Oct 2024 13:53:15 +0000

Introdução

Com a introdução dos Records no Java, muitos desenvolvedores estão aproveitando essa nova funcionalidade para criar classes imutáveis de maneira mais concisa. No entanto, ao testar APIs que retornam objetos JSON baseados em Records, alguns desenvolvedores podem encontrar problemas ao usar o jsonPath("$") no MockMvc para verificar o conteúdo da resposta.

Este artigo aborda o problema e apresenta uma solução simples usando o método content().json().

O Problema

Ao usar MockMvc para testar endpoints que retornam JSON, é comum usar o jsonPath() para verificar o conteúdo da resposta. No entanto, ao trabalhar com Records, você pode encontrar erros ao tentar usar jsonPath("$") para verificar o tamanho ou o conteúdo da resposta JSON.

Por exemplo, o seguinte código pode falhar:

Esse erro ocorre porque o jsonPath("$") pode não funcionar corretamente com a estrutura de Records, especialmente ao tentar acessar o objeto raiz ou verificar o tamanho da resposta.

A Solução: Usando content().json()

Uma solução simples e eficaz para esse problema é usar o método content().json() do MockMvc. Esse método permite verificar diretamente o conteúdo da resposta JSON, sem depender do jsonPath().

Aqui está um exemplo de como você pode usar content().json() para verificar o tamanho da resposta JSON:

Neste exemplo, o método content().json() está verificando se a resposta JSON contém exatamente 3 objetos, sem precisar usar o jsonPath("$").

Verificando o Conteúdo Exato

Além de verificar o número de objetos, você pode usar content().json() para verificar o conteúdo exato da resposta JSON. Por exemplo:

Esse código verifica se a resposta JSON contém exatamente os objetos esperados, com os campos id e name.

Verificação Parcial

Se você não precisar verificar todos os campos, pode usar um JSON parcial:

O segundo parâmetro false indica que campos extras no JSON de resposta serão ignorados.

Conclusão

Se você está enfrentando problemas ao usar jsonPath("$") com Records, a solução mais simples é usar o método content().json() do MockMvc. Ele permite verificar o conteúdo da resposta JSON de maneira direta e flexível, sem depender do jsonPath().

Essa abordagem é especialmente útil quando você precisa verificar o número de objetos no JSON ou o conteúdo exato da resposta.

Espero que este artigo ajude a resolver os problemas que você está enfrentando ao testar APIs com Records no Java. Se você tiver mais dúvidas ou sugestões, fique à vontade para compartilhar!

Utilizando ProblemDetail no Spring para tratamento de erros

Gilson Silva — Mon, 30 Sep 2024 19:21:11 +0000

O Spring Framework oferece diversas formas de lidar com exceções e erros em APIs REST. Uma das abordagens mais modernas e recomendadas é o uso do ProblemDetail, que segue o padrão RFC 7807 para fornecer detalhes sobre problemas HTTP de forma estruturada e padronizada.

Neste artigo, vamos explorar como utilizar o ProblemDetail no Spring para tratar exceções e retornar respostas de erro mais informativas e padronizadas para o cliente.

O que é o ProblemDetail?
O ProblemDetail é uma classe introduzida no Spring para facilitar o tratamento de erros em APIs REST. Ele permite que você forneça informações detalhadas sobre o erro ocorrido, como o status HTTP, uma mensagem descritiva, e até mesmo propriedades adicionais, como o timestamp do erro ou a categoria do problema.

Exemplo de Uso
Vamos considerar um cenário onde estamos criando um planeta em uma API, mas o nome do planeta já existe no banco de dados. Nesse caso, uma exceção do tipo DataIntegrityViolationException será lançada, e queremos retornar uma resposta HTTP com status 409 Conflict e detalhes sobre o erro.

Teste de Integração
Primeiro, criamos um teste para garantir que, ao tentar criar um planeta com um nome já existente, a API retorne o status 409 Conflict.

@Test
@DisplayName("Create Planet with existing name return conflict")
void createPlanet_WithExistingName_ReturnConflict() throws Exception {
    when(service.create(any(Planet.class))).thenThrow(DataIntegrityViolationException.class);

    mockMvc.perform(post("/planets")
                    .content(mapper.writeValueAsString(PLANET_REQUEST))
                    .contentType(APPLICATION_JSON))
            .andExpect(status().isConflict());
}

Tratamento da Exceção com ProblemDetail
Para capturar a exceção DataIntegrityViolationException e retornar uma resposta detalhada, utilizamos o @ExceptionHandler no Spring. O ProblemDetail nos permite fornecer informações adicionais sobre o erro, como o título, detalhes, e até mesmo propriedades personalizadas, como o StackTrace e o TimeStamp.

@ExceptionHandler(DataIntegrityViolationException.class)
public ProblemDetail handleConflict(DataIntegrityViolationException ex) {
    var problemDetail = ProblemDetail.forStatusAndDetail(HttpStatus.CONFLICT, ex.getLocalizedMessage());
    problemDetail.setTitle("Dado informado já existe");
    problemDetail.setDetail("É preciso informar um dado válido");
    problemDetail.setProperty("StackTrace", ex.getStackTrace());
    problemDetail.setProperty("Categoria", "API");
    problemDetail.setProperty("TimeStamp", Instant.now());

    return problemDetail;
}

Explicação do Código

@ExceptionHandler(DataIntegrityViolationException.class): Este método será chamado sempre que uma exceção do tipo DataIntegrityViolationException for lançada.
ProblemDetail.forStatusAndDetail(HttpStatus.CONFLICT, ex.getLocalizedMessage()): Cria um objeto ProblemDetail com o status HTTP 409 Conflict e a mensagem de erro da exceção.
setTitle e setDetail: Definem o título e os detalhes do problema, que serão exibidos na resposta.
setProperty: Adiciona propriedades personalizadas ao ProblemDetail, como o StackTrace, a categoria do erro e o timestamp do momento em que o erro ocorreu.

Resposta Esperada
Quando a exceção for lançada, a API retornará uma resposta no seguinte formato:

{
  "type": "about:blank",
  "title": "Dado informado já existe",
  "status": 409,
  "detail": "É preciso informar um dado válido",
  "instance": "/planets",
  "StackTrace": [...],
  "Categoria": "API",
  "TimeStamp": "2023-10-05T14:48:00Z"
}

Conclusão
O uso do ProblemDetail no Spring permite que você forneça respostas de erro mais detalhadas e padronizadas, melhorando a experiência do consumidor da API e facilitando a depuração. Além disso, o ProblemDetail é altamente personalizável, permitindo que você adicione informações específicas sobre o erro, como o StackTrace e o TimeStamp.

Teste de Integração com Banco de Dados

Gilson Silva — Fri, 27 Sep 2024 18:55:20 +0000

Introdução

Testes de integração são uma parte essencial da pirâmide de testes, pois garantem que diferentes partes do sistema funcionem corretamente quando integradas. No contexto de uma aplicação que utiliza um banco de dados, os testes de integração verificam se as operações de persistência de dados estão funcionando conforme o esperado. Neste artigo, vamos explorar um exemplo simples de teste de integração com o banco de dados usando a classe PlanetRepositoryTest.

O que é o PlanetRepositoryTest?

A classe PlanetRepositoryTest é um teste de integração que verifica se o repositório de planetas (PlanetRepository) consegue salvar e recuperar corretamente um planeta no banco de dados. Esse teste utiliza o Spring Boot e a anotação @DataJpaTest, que configura automaticamente um ambiente de teste com JPA e um banco de dados em memória.

Estrutura do Teste

Aqui está a estrutura básica do teste de integração:

package br.com.starwars.domain;

import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest;
import org.springframework.boot.test.autoconfigure.orm.jpa.TestEntityManager;

import static br.com.starwars.common.PlanetConstants.PLANET;
import static org.assertj.core.api.Assertions.assertThat;

@DataJpaTest
class PlanetRepositoryTest {

    @Autowired
    PlanetRepository repository;

    @Autowired
    TestEntityManager entityManager;

    @Test
    @DisplayName("Create Planet with valid data return Planet")
    void createPlanet_WithValidData_ReturnPlanet() {
        var savedPlanet = repository.save(PLANET);

        // sut: system under test (sistema em teste)
        var sut = entityManager.find(Planet.class, savedPlanet.getId());

        assertThat(sut).isNotNull();
        assertThat(sut.getName()).isEqualTo(PLANET.getName());
        assertThat(sut.getClimate()).isEqualTo(PLANET.getClimate());
        assertThat(sut.getTerrain()).isEqualTo(PLANET.getTerrain());
    }
}

Explicação do Código

1. Anotação @DataJpaTest:

A anotação @DataJpaTest é usada para configurar um ambiente de teste focado em JPA. Ela configura automaticamente um banco de dados em memória e escaneia apenas os componentes relacionados à persistência de dados, como repositórios.

2. Injeção de Dependências:

O repositório PlanetRepository e o TestEntityManager são injetados automaticamente pelo Spring. O TestEntityManager é uma ferramenta útil para interagir diretamente com o banco de dados durante os testes.

3. Teste createPlanet_WithValidData_ReturnPlanet():

Este teste verifica se o repositório consegue salvar um planeta com dados válidos e, em seguida, recuperá-lo corretamente do banco de dados.
O planeta é salvo usando o método save() do repositório.
O TestEntityManager é usado para buscar o planeta salvo diretamente do banco de dados, garantindo que ele foi persistido corretamente.
O teste então verifica se o planeta recuperado não é nulo e se seus atributos (nome, clima e terreno) correspondem aos valores esperados.

Elevação da Pirâmide de Testes

A pirâmide de testes é um conceito que sugere que a maior parte dos testes deve ser composta por testes unitários, seguidos por testes de integração e, por fim, testes de ponta a ponta (end-to-end). Testes de integração, como o PlanetRepositoryTest, são mais lentos e complexos do que testes unitários, pois envolvem a interação com componentes externos, como o banco de dados. No entanto, eles são essenciais para garantir que as diferentes partes do sistema funcionem corretamente quando integradas.

Neste exemplo, o teste de integração está focado na camada de persistência de dados, garantindo que o repositório funcione corretamente com o banco de dados. Ele complementa os testes unitários, que testam o comportamento isolado de classes e métodos, elevando a pirâmide de testes ao garantir que a integração entre o repositório e o banco de dados está funcionando conforme o esperado.

Extra:

Conclusão

O teste de integração PlanetRepositoryTest é uma parte importante do processo de desenvolvimento, pois garante que o repositório de planetas funcione corretamente com o banco de dados. Ao usar o Spring Boot e a anotação @DataJpaTest, podemos configurar um ambiente de teste eficiente e verificar se as operações de persistência estão funcionando conforme o esperado. Esse tipo de teste é essencial para garantir a qualidade e a confiabilidade da aplicação, especialmente em sistemas que dependem de interações com bancos de dados.

#Desenvolvimento #Programação #Tecnologia #Inovação #Código #DevLife #StackSpot #Java #TestesAutomatizados #Desenvolvedor #TechLife #Software

Forem: Gilson Silva

Hot-Reload de Configurações de Portal Manager via /actuator/refresh no Spring Boot

1. Como funciona o /actuator/refresh?

2. Fontes Externas Suportadas

3. Exemplo: AWS Parameter Store/Secrets Manager

a) Dependências

b) Configuração do application.properties

c) Uso no código

d) Processo de atualização

4. Observações Importantes

5. Fluxo Resumido

Conclusão

Simulando um ambiente AWS com LocalStack

O que é o LocalStack?

Passo a Passo para Configurar o LocalStack

1. Pré-requisitos

2. Instalando o LocalStack

3. Configurando a AWS CLI

4. Criando Recursos Simulados

5. Testando Funções Lambda

Vantagens do LocalStack

Exemplo de Configuração Completa

Dockerfile

Buildspec para Testes

Conclusão

📝 Logar de Maneira Sistemática: A Técnica dos 5 W

Testes Parametrizados com JUnit 5: Um Exemplo Prático 🚀

Testes Subcutâneos - Comparação entre TestRestTemplate e WebTestClient em Testes de Integração 🧑‍💻

Como Resolver Problemas com jsonPath("$") ao Usar Records no Java ❌😢

Espero que este artigo ajude a resolver os problemas que você está enfrentando ao testar APIs com Records no Java. Se você tiver mais dúvidas ou sugestões, fique à vontade para compartilhar!

Utilizando ProblemDetail no Spring para tratamento de erros

Teste de Integração com Banco de Dados

Introdução

1. Como funciona o `/actuator/refresh`?