Idea artikel ini adalah untuk menunjukkan bahawa adalah mungkin untuk membangunkan aplikasi dengan Spring bermula dengan liputan ujian, memberikan keselamatan yang lebih besar bahawa apa yang sedang dibangunkan sudah berfungsi seperti yang diharapkan, dan mengelakkan kemalasan melaksanakan ujian " selepas semuanya sudah siap”, hanya untuk mencapai pintu kualiti firma.
Jadi mari kita pergi, sebahagiannya…
Membolehkan anda menguji aplikasi secara melintang, melalui semua itu, melalui semua titik, jadi panggilan HTTP, akan melalui semua komponen kodnya dan menguji cara ia berfungsi antara satu sama lain. Ini akan memberi anda jaminan bahawa keseluruhan aliran aplikasi berfungsi, bagaimanapun, ia biasanya merupakan jenis ujian yang lebih mahal, ya, mahal, kerana ia menggunakan lebih banyak sumber, ukuran ini hanya memerhatikan masa ujian ini diambil untuk dilaksanakan .
Jangan ragu untuk mempersoalkan pandangan saya di sini
Niat di sini, walaupun ia adalah untuk mula membina aplikasi anda menggunakan ujian integrasi, tidak semestinya TDD, idea TDD adalah untuk membina ujian unit, seperti yang kami katakan sebelum ini, ujian unit mempunyai butiran yang lebih besar, ia berhasrat untuk menguji setiap unit kod tanpa bergantung pada komponen yang disepadukan ke dalamnya, oleh itu tidak tertakluk kepada tingkah laku di luar komponen yang diuji.
Dengan mengambil kira perkara ini, ini mungkin satu cara untuk membina aplikasi anda, tetapi adalah penting untuk diingat bahawa ujian penyepaduan mengambil lebih banyak masa untuk dilaksanakan, oleh itu menangguhkan kitaran maklum balas pantas yang dicadangkan oleh TDD. Namun, ya, anda mempunyai pembangunan yang dilindungi oleh ujian.
Idea di sini adalah untuk menyediakan projek mudah, API Rehat dan 4 operasi asasnya (CRUD lama yang bagus, anda tahu apa itu CRUD yang betul? Anda tidak, tidak mengapa, baca di sini) dan bina setiap titik akhir daripadanya ujian wajar.
Kami kemudiannya akan mempunyai API pesanan perkhidmatan:
POS /pesanan: Anda akan menerima permintaan berikut:
{ "description": "Some description" }
Ia akan membuat pesanan perkhidmatan dalam pangkalan data dan mengembalikan pesanan yang dibuat seperti berikut:
{ "id": "xxxxxxxxxxxxx", "description": "Some description", "created_at": "2024-02-21T23:58:01:000z", "updated_at": "2024-02-21T23:58:01:000z", "status": "OPENED" }
DAPATKAN /pesanan: Senaraikan semua pesanan bank (menyenaraikan semuanya salah, sudah tentu, tetapi mari kita pergi beberapa bahagian).
Akan mengembalikan senarai pesanan perkhidmatan daripada pangkalan data dengan format berikut:
```json [ { "id": "xxxxxxxxxxxxx", "description": "Some description", "created_at": "2024-02-21T23:58:01:000z", "updated_at": "2024-02-21T23:58:01:000z", "status": "OPENED" } ] ```
PUT /orders/:id: Anda akan menerima permintaan berikut seperti yang ditunjukkan di bawah dan id pesanan sedia ada dimaklumkan dalam laluan permintaan.
{ "description": "Some description", "status": "CLOSED" }
Ia akan membuat pesanan perkhidmatan dalam pangkalan data dan mengembalikan pesanan yang dibuat seperti berikut:
```json { "id": "xxxxxxxxxxxxx", "description": "Some description", "created_at": "2024-02-21T23:58:01:000z", "updated_at": "2024-02-23T13:35:09:135z", "status": "OPENED" } ```
Jika id pesanan yang tidak wujud dimasukkan, ralat dengan StatusCode 404 mesti dikembalikan.
DAPATKAN /order/:id
Ia akan menerima id pesanan sedia ada yang dimaklumkan dalam laluan permintaan, menanyakan pangkalan data dan mengembalikan rekod seperti berikut:
{ "id": "xxxxxxxxxxxxx", "description": "Some description", "created_at": "2024-02-21T23:58:01:000z", "updated_at": "2024-02-23T13:35:09:135z", "status": "OPENED" }
Jika id pesanan yang tidak wujud dimasukkan, ralat dengan kod status 404 mesti dikembalikan.
Kami akan menggunakan Java abadi di sini
Dan beberapa perkongsiannya yang berjaya:
Ini akan menjadi teras aplikasi kami, tetapi kami akan menambah beberapa lib untuk tujuan kami. Mula-mula pangkalan data H2, di sini anda mesti bertanya kepada diri sendiri: "- Dua pangkalan data?". H2 hanya akan digunakan untuk ujian kami, ia adalah pangkalan data yang berfungsi dalam ingatan dan akan sesuai untuk tujuan kami di sini, dan dalam banyak senario aplikasi sebenar, selagi pangkalan data digunakan untuk tujuan yang betul, menyimpan data ( anda perselisihan faham di sini juga, cuma pendapat saya yang trauma).
Untuk mencipta projek kami akan menggunakan tapak web Spring Initializr. Mencipta sesuatu seperti ini:
Beri perhatian kepada lib yang ditambahkan di sini dan versi yang dipilih, lihat:
Kami akan menggunakan Maven untuk mengurus kebergantungan dan binaan projek kami.
Conforme podemos ver na imagem acima ao clicar no botão “Generate” um arquivo será gerado .zip com um projeto base, descompactaremos em lugar de preferência e iremos abri-lo na nossa IDE preferida, aqui usaremos Intellij CE. Isso pode ser importante ressaltar por que alguns exemplos podem ser dados estritamente usando a ferramenta, por simples questão de agilidade, mas tendo o conhecimento necessário, qualquer ferramenta serve.
A estrutura resultante dentro da pasta deve ser algo assim:
Veja que por padrão já teremos um package test, será nele que iremos criar nosso teste. Vamos criar um package e chamá-lo de integration:
Vamos começar por um teste simples que nos permita estruturar nossa classe de teste, vamos testar nosso primeiro endpoint que irá nos retornar uma lista vazia das nossas ordens. Primeiro momento vamos criar um teste somente para efetuar toda a configuração necessária para nosso teste.
Sabendo que temos um teste de integração e nosso contexto terá um banco de dados, vamos começar fornecendo ao Spring as configurações que ele precisa para alcançar estes recursos, no nosso caso o banco de dados H2(lembra dele, mas fixando, somente para os nosso testes). Assim criaremos um arquivo application.yaml em src/test/resources com o seguinte conteúdo:
spring: datasource: driver-class-name: org.h2.Driver url: jdbc:h2:mem:testdb username: sa password: password jpa: database-platform: org.hibernate.dialect.H2Dialect hibernate: ddl-auto: create-drop show-sql: true h2: console: enabled: true
Dentro da pasta acima que acabamos de criar vamos criar uma classes que chamaremos OrderControllerIntegrationTest, ela tera a seguinte estrutura:
package com.seuprojeto.integrationtest.integration; import org.junit.jupiter.api.TestInstance; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.boot.context.properties.EnableConfigurationProperties; import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc; import org.springframework.boot.test.context.SpringBootTest; import org.springframework.test.annotation.DirtiesContext; import org.springframework.test.web.servlet.MockMvc; @TestInstance(TestInstance.Lifecycle.PER_CLASS) @AutoConfigureMockMvc @DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD) @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) public class OrderControllerIntegrationTest { private static final String ORDER_URL = "/orders"; @Autowired MockMvc mockMvc; }
Vamos falar sobre cada uma das linhas:
Passamos mais detalhadamente por essas linhas por que no contexto de configuração de testes essa classes são bastante importantes e requerem um pouco de detalhamento sobre elas, as demais classes são coisas mais “simples” e vamos falar em blocos.
private static final String ORDER_URL = "/orders"; @Autowired MockMvc mockMvc;
Declaramos uma propriedade estática para o uri, porque iremos repeti-la algumas vezes e por boa prática vamos guardá-la em uma variável e na sequência injetamos o objeto MockMvc que usaremos para fazer nossas chamadas HTTP e fazer nossos testes.
Este primeiro só irá garantir que todo o aparato de configurações estejam funcionando, então neste momento não iremos no aprofundar muito, iremos fazer isso a medida que nossos cenários de teste se tornem mais maduros.
@Test void shouldReturn200WhenGetAllOrders() throws Exception { mockMvc.perform(MockMvcRequestBuilders.get(ORDER_URL)) .andExpect(status().isOk()) .andReturn(); }
Considerando que não temos nenhuma entidade qualquer criada em nossa aplicação, então este teste espera que ao fazer uma chamada GET para a URI /orders devemos ter como retorno um StatusCode 200.
Uma adendo aqui, ao construir o caso de teste na nossa classe, para executar basta clicar no botão exibido pela IDE (Eu disse que usaríamos dos recursos da IDE):
Ao executar este teste receberemos um caloroso 404, obviamente, já que não implementamos esta rota em nossa aplicação ainda.
Então vamos fazer este teste passar. Para isso iremos criar a controller que irá responder a nossa chamada, ignore aqui a maneira com que classes e packages serão criados, não iremos discutir sobre isso neste artigo, além do mais considerando que o spring é responsável por gerenciar a injeção de dependência, a estrutura de como as packages são criadas não é necessariamente importante. Vamos lá, iremos criar a seguinte package com/seuprojeto/integration/app/controller:
Dentro dela iremos criar nossa controller, como abaixo:
package com.seuprojeto.integrationtest.app.controller; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; import java.util.List; @RestController @RequestMapping("/orders") public class OrderController { @GetMapping public List getAllOrders() { return List.of(); } }
Não é o que pretendemos, mas essa simples implementação fará nossos testes passarem com sucesso, isso irá validar que nosso testes estão, por hora, configurados com sucesso.
Bem, agora vamos um pouco mais fundo, começar a fazer testes que, de fato, irão atravessar camadas da nossa aplicação. Vamos implementar o caso de para criação de uma ordem e persistir no banco de dados.
Este será nosso segundo caso de teste, mais uma vez vamos por partes aqui, não é um teste conforme esperado e iremos melhora-lo:
@Test void shouldReturn201WhenCreateOrder() throws Exception { var response = mockMvc.perform(MockMvcRequestBuilders.post(ORDER_URL).content("{\"description\": \"some description\"}").contentType(MediaType.APPLICATION_JSON)) .andExpect(status().isCreated()) .andReturn(); System.out.println(response.getResponse().getContentAsString()); Assertions.assertTrue(response.getResponse().getContentAsString().contains("description")); Assertions.assertTrue(response.getResponse().getContentAsString().contains("some description")); Assertions.assertTrue(response.getResponse().getContentAsString().contains("id")); Assertions.assertTrue(response.getResponse().getContentAsString().contains("createdAt")); Assertions.assertTrue(response.getResponse().getContentAsString().contains("updatedAt")); Assertions.assertTrue(response.getResponse().getContentAsString().contains("status")); Assertions.assertTrue(response.getResponse().getContentAsString().contains("OPENED")); }
Se executarmos agora teremos um StatusCode 405, ou seja, o rota /orders foi encontrada, mas o método POST não esta implementado, vamos cuidar disso.
Primeiro vamos criar nossa classe de domínio Order, ela será nossa e também nosso entidade para banco de dados. Criaremos em um novo package com/seuprojeto/integration/domain e dentro dele as classes abaixo:
package com.seuprojeto.integrationtest.domain; import jakarta.persistence.*; import java.time.LocalDateTime; import java.util.UUID; @Entity @Table(name = "orders", schema = "public") public class Order { @Id @GeneratedValue(strategy = GenerationType.UUID) private UUID id; private String description; private LocalDateTime createdAt; private LocalDateTime updatedAt; private Status status; public Order() { } public Order(UUID id, String description, LocalDateTime createdAt, LocalDateTime updatedAt, Status status) { this.id = id; this.description = description; this.createdAt = createdAt; this.updatedAt = updatedAt; this.status = status; } public static Order create(String description) { return new Order(UUID.randomUUID(), description, LocalDateTime.now(), LocalDateTime.now(), Status.OPENED); } public UUID getId() { return id; } public String getDescription() { return description; } public LocalDateTime getCreatedAt() { return createdAt; } public LocalDateTime getUpdatedAt() { return updatedAt; } public Status getStatus() { return status; } }
package com.seuprojeto.integrationtest.domain; public enum Status { OPENED, CLOSED, CANCELED; }
Pensando no isolamento das nossas classes de domínio das extremidades da nossa aplicação não iremos expor-las nas bordas do sistema, então criaremos dois records DTO para fazer a comunicação com partes eternas de nossos sistemas, no caso a interface HTTP Rest, assim criaremos duas classes em com/seuprojeto/integration/app/controller/dto .
Este primeiro é a estrutura que irá receber o JSON para criação de uma ordem, conforme contrato estabelecido.
public record CreateOrderDto(String description) { }
Este segundo tem o contrato conforme esperado para saída do método de criação.
package com.seuprojeto.integrationtest.app.controller.dto; import com.seuprojeto.integrationtest.domain.Order; public record OrderCreatedDto(String id, String description, String status, String createdAt, String updatedAt) { public static OrderCreatedDto from(Order order) { return new OrderCreatedDto( order.getId().toString(), order.getDescription(), order.getStatus().name(), order.getCreatedAt().toString(), order.getUpdatedAt().toString()); } }
E agora iremos criar a classe de acesso a banco de dados, normalmente aqui eu adicionaria mais uma camada, de usecase, para que cada fluxo da aplicação ficasse devidamente separado, mas não irei me alongar ainda mais.
Então vamos ajustar nossa controller para permitir atender nossos requisitos de teste, assim nossa classe ficará assim:
package com.seuprojeto.integrationtest.app.controller; import com.seuprojeto.integrationtest.app.controller.dto.CreateOrderDto; import com.seuprojeto.integrationtest.app.controller.dto.OrderCreatedDto; import com.seuprojeto.integrationtest.domain.Order; import com.seuprojeto.integrationtest.infra.OrderRepository; import org.springframework.http.HttpStatus; import org.springframework.web.bind.annotation.*; import java.util.List; @RestController @RequestMapping("/orders") public class OrderController { private final OrderRepository repository; public OrderController(OrderRepository repository) { this.repository = repository; } @GetMapping public List getAllOrders() { return List.of(); } @PostMapping @ResponseStatus(HttpStatus.CREATED) public OrderCreatedDto createOrder(@RequestBody CreateOrderDto createOrderDto) { final Order order = Order.create(createOrderDto.description()); final Order orderSaved = this.repository.save(order); return OrderCreatedDto.from(orderSaved); } }
Evoilá, nosso teste irá passar com sucesso.
Mas voltemos a composição do nosso teste, ele não muito apresentável, e além de tudo passível de algumas falhas. Primeiro que não esta legal é o fato de que estamos usando muitas validações com string, isso fica ruim para mater além de um tanto verboso. Vamos fazer algumas melhorias então, veja que nossa classe controller recebe e retorna classes, podemos utilizar as mesmas para compor nosso teste. Então vamos fazer alterações na nossa classe de teste, primeiro adicionando um novo objeto:
package com.seuprojeto.integrationtest.integration; import com.fasterxml.jackson.databind.ObjectMapper; ... class OrderControllerIntegrationTest { private static ObjectMapper objectMapper = new ObjectMapper(); ...
Obs.: Algumas partes da classe foram omitidas, para dar enfase ao que foi adicionado.
ObjectMapper usaremos para fazer a serialização das nossas classes(records) de entrada e saída, melhorando a compreensão de nossos testes. Vamos refatorar nosso caso de teste conforme abaixo:
... import java.util.regex.Pattern; ... @Test void shouldReturn201WhenCreateOrder() throws Exception { final String description = "some description"; final CreateOrderDto createOrderDto = new CreateOrderDto(description); final String payload = objectMapper.writeValueAsString(createOrderDto); final MvcResult response = this.mockMvc.perform(MockMvcRequestBuilders.post(ORDER_URL).content(payload).contentType(MediaType.APPLICATION_JSON)) .andExpect(status().isCreated()) .andReturn(); OrderCreatedDto orderCreatedDto = objectMapper.readValue(response.getResponse().getContentAsString(), OrderCreatedDto.class); Pattern pattern = Pattern.compile("^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$"); Assertions.assertNotNull(orderCreatedDto.id()); Assertions.assertTrue(pattern.matcher(orderCreatedDto.id()).matches()); Assertions.assertEquals(description, orderCreatedDto.description()); Assertions.assertNotNull(orderCreatedDto.createdAt()); Assertions.assertNotNull(orderCreatedDto.updatedAt()); Assertions.assertEquals("OPENED", orderCreatedDto.status()); }
Agora nosso teste estão diretamente vinculados a nossas classes, assim quando houverem alterações nessas, será mais fácil identificar onde os teste foram quebrados, tão quanto fazer os ajustes necessários, tão como ficou mais legível o que está sendo testado.
Vamos agora testar nosso endpoint de alteração, neste endpoint vimos que necessário informar o campo status, então vamos criar um record específico para este endpoint, conforme abaixo:
package com.seuprojeto.integrationtest.integration.app.controller.dto; public record UpdateOrderDto(String description, String status) { }
Vamos também alterar uma classe já existe, a classe order, adicionando a ela um método que irá atualizar os dados da classe. Adicionaremos o método abaixo:
... public void update(String description, String status) { this.description = description; this.status = Status.valueOf(status.toUpperCase()); this.updatedAt = LocalDateTime.now(); } ...
E então criaremos o método na controller
... @PutMapping("/{id}") public OrderCreatedDto updateOrder(@PathVariable String id, @RequestBody UpdateOrderDto updateOrderDto) { final UUID uuid = UUID.fromString(id); final Order order = this.repository.findById(uuid).orElseThrow(); order.update(updateOrderDto.description(), updateOrderDto.status()); final Order orderSaved = this.repository.save(order); return OrderCreatedDto.from(orderSaved); }
Neste teste teremos uma peculiaridade, pois para alterar uma ordem precisamos primeiro, precisamos primeiro saber de uma ordem já existente, pois a uri para atualizar um ordem exige como parâmetro um id, então faremos a chamada do endpoint de criação de ordem e usaremos o retorno deste para fazer a chamada no nosso endpoint PUT.
@Test void shouldReturn200WhenPutAnExistentOrder() throws Exception { final String description = "some description"; final CreateOrderDto createOrderDto = new CreateOrderDto(description); final String payload = objectMapper.writeValueAsString(createOrderDto); final MvcResult response = this.mockMvc.perform(MockMvcRequestBuilders.post(ORDER_URL).content(payload).contentType(MediaType.APPLICATION_JSON)) .andExpect(status().isCreated()) .andReturn(); final OrderCreatedDto orderCreatedDto = objectMapper.readValue(response.getResponse().getContentAsString(), OrderCreatedDto.class); final String newDescription = "new description"; final String newStatus = "CLOSED"; final UpdateOrderDto updateOrderDto = new UpdateOrderDto(newDescription, newStatus); final String updatePayload = objectMapper.writeValueAsString(updateOrderDto); final MvcResult updateResponse = this.mockMvc.perform(MockMvcRequestBuilders.put(ORDER_URL + "/" + orderCreatedDto.id()).content(updatePayload).contentType(MediaType.APPLICATION_JSON)) .andExpect(status().isOk()) .andReturn(); final OrderCreatedDto updatedOrderCreatedDto = objectMapper.readValue(updateResponse.getResponse().getContentAsString(), OrderCreatedDto.class); Assertions.assertEquals(newDescription, updatedOrderCreatedDto.description()); Assertions.assertEquals(newStatus, updatedOrderCreatedDto.status()); }
Embora este teste com certeza esta passando sem erro, voltemos a ele. Este teste faz uma simples validação se é retornado um StatusCode 200, vamos alterar ele já que agora temos de fato nossa aplicação persistindo em banco de dados, então vamos alterar primeiramente o método que retorna a lista de ordens persistida no banco:
@GetMapping public ListgetAllOrders() { return this.repository.findAll().stream() .map(OrderCreatedDto::from) .toList(); }
E nossa classe de teste iremos alterar assim:
@Test void shouldReturn200WhenGetAllOrders() throws Exception { final MvcResult response = mockMvc.perform(MockMvcRequestBuilders.get(ORDER_URL)) .andExpect(status().isOk()) .andReturn(); Assertions.assertTrue(response.getResponse().getContentAsString().contains("[]")); }
Executando todos os testes veremos que eles passarão com sucesso.
E ai deve vir a sua cabeça, ao executar todos os testes veremos que método que criação de ordens são escutados antes, no entanto, vimos que testamos um retorno de lista vazia, por que? É importante compreender isso, primeiro lembra-se da annotationDirtiesContext? Bem, ela garante que a cada teste nosso contexto seja reiniciado, assim os dados criados em cada um dos teste são “descartados”, a cada teste o banco que é um banco H2 em memória, é recriado, isso nos garantes isolamentos dos testes, impedindo que um caso de teste influencie outro, causando o que chamamos deflaky test. Essa hipótese pode ser testa simplesmente comentando a linha:
//@DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD)
E executando os testes novamente. Veja embora isso causa esta falta de isolamento dos teste reiniciar o contexto do Spring consome mais recursos. É uma opção não habilitar esta opção, mas isso nos exigirá algumas configurações adicionais em nossos testes.
Tempo de execução com annotation que reinicia o contexto do Spring
Tempo de execução sem o annotation que reinicia o contexto Spring
Podemos ver que temos um ganho de tempo na execução considerável, em uma suíte de testes extensa, este ganho pode ser considerável, vamos então fazer as configurações necessário e vamos seguir assim para ser mais rápida a nossa execução. Esta é uma decisão que tem alguns tradeoffs, então antes de tomar essa decisão avalie os riscos. Vamos as configurações na nossa classe de testes:
package com.seuprojeto.integrationtest.integration; ... import com.seuprojeto.integrationtest.infra.OrderRepository; ... import org.junit.jupiter.api.BeforeEach; ... import org.springframework.beans.factory.annotation.Autowired; ... @TestInstance(TestInstance.Lifecycle.PER_CLASS) @AutoConfigureMockMvc @EnableConfigurationProperties //@DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD) @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) class OrderControllerIntegrationTest { @Autowired OrderRepository orderRepository; ... @Autowired MockMvc mockMvc; @BeforeEach void setUp() { this.orderRepository.deleteAll(); } ... }
O que mudamos aqui é o seguinte, injetamos a nossa classe OrderRepository e adicionamos o método setup. O método setup possui a annotation @BeforeEach, isso irá fazer com que o conteúdo dele seja executado sempre antes de executar um novo caso de teste. Dentro dele chamamos um método que remove todos os registros da tabela, assim evitando que nosso casos de teste tenham implicações uns sobre os outros (ao menos neste caso).
Vamos testar o endpoint capaz de retornar uma única ordem com base em seu id. Este será um teste mais fácil visto que não teremos nada de novo para criar aqui para que o teste funcione. Vejamos como fica o método que retorna a ordem de serviço na controller:
@GetMapping("/{id}") public OrderCreatedDto getOrder(@PathVariable String id) { final UUID uuid = UUID.fromString(id); final Order order = this.repository.findById(uuid).orElseThrow(); return OrderCreatedDto.from(order); }
E o teste será implementado assim:
@Test void shouldReturn200WhenGetAnExistentOrder() throws Exception { final String description = "some description"; final CreateOrderDto createOrderDto = new CreateOrderDto(description); final String payload = objectMapper.writeValueAsString(createOrderDto); final MvcResult response = this.mockMvc.perform(MockMvcRequestBuilders.post(ORDER_URL).content(payload).contentType(MediaType.APPLICATION_JSON)) .andExpect(status().isCreated()) .andReturn(); final OrderCreatedDto orderCreatedDto = objectMapper.readValue(response.getResponse().getContentAsString(), OrderCreatedDto.class); final MvcResult getResponse = this.mockMvc.perform(MockMvcRequestBuilders.get(ORDER_URL + "/" + orderCreatedDto.id())) .andExpect(status().isOk()) .andReturn(); final OrderCreatedDto getOrderCreatedDto = objectMapper.readValue(getResponse.getResponse().getContentAsString(), OrderCreatedDto.class); Assertions.assertEquals(orderCreatedDto.id(), getOrderCreatedDto.id()); Assertions.assertEquals(orderCreatedDto.description(), getOrderCreatedDto.description()); Assertions.assertEquals(orderCreatedDto.status(), getOrderCreatedDto.status()); }
Note que mais uma vez usamos a estratégia de adicionar um item através do método de criação e depois consulta-lo. É possível fazer essa inserção de dados diretamente no banco, já que o repository foi injetado em nossa classe de teste, particularmente acredito que isso é manipular diretamente os dados e fugiria o objetivo deste teste que é fazer testar somente através da interface que a aplicação irá exposta.
Este é o teste de irá remover um registro do banco de dados, vamos ao método da controller:
@DeleteMapping("/{id}") @ResponseStatus(HttpStatus.NO_CONTENT) public void deleteOrder(@PathVariable String id) { final UUID uuid = UUID.fromString(id); this.repository.deleteById(uuid); }
Nosso caso de teste:
@Test void shouldReturn204WhenDeleteAnExistentOrder() throws Exception { final String description = "some description"; final CreateOrderDto createOrderDto = new CreateOrderDto(description); final String payload = objectMapper.writeValueAsString(createOrderDto); final MvcResult response = this.mockMvc.perform(MockMvcRequestBuilders.post(ORDER_URL).content(payload).contentType(MediaType.APPLICATION_JSON)) .andExpect(status().isCreated()) .andReturn(); final OrderCreatedDto orderCreatedDto = objectMapper.readValue(response.getResponse().getContentAsString(), OrderCreatedDto.class); this.mockMvc.perform(MockMvcRequestBuilders.delete(ORDER_URL + "/" + orderCreatedDto.id())) .andExpect(status().isNoContent()); }
Mais uma vez chamamos o método que cria uma ordem e somente depois executamos o método que irá excluir/deletar o registro.
Veremos que este caso de teste passa sem problema, aqui basicamente fechamos todos o métodos do nosso CRUD. Mas vamos pensar no seguinte cenário, para este último caso, embora ele tenho funcionado corretamente podemos fazer uma validação adicional, pense que se a ordem foi removida, então significa que que se eu fizer aquele GET pelo id eu deveria ter um retorno 404. A implementação ficaria algo assim, este código adicionado ao fim do mesmo caso de teste:
@Test void shouldReturn204WhenDeleteAnExistentOrder() throws Exception { ... this.mockMvc.perform(MockMvcRequestBuilders.get(ORDER_URL + "/" + orderCreatedDto.id())) .andExpect(status().isNotFound()) .andReturn(); }
Porém ao executar o teste novamente com esta nova parte implementação teste deixará de passar, pois não fizemos nenhuma implementação que nos retorne o StatusCode 404. Na verdade é retornada uma exceção. Bem é isso que implementamos no método de consulta:
Se lembramos na nossa proposta de implementação este mesmo método 404 é pedido também em outros métodos no próprio DELETE e no PUT também. Então vamos aplicar uma solução que possa ser aplicada em todas as situações.
Para isso iremos gerar uma exception personalizada, que será usada sempre que eu tiver essa situação de ordem não encontrada. Na package com/seuprojeto/integration/domain iremos criar a seguinte classe:
package com.seuprojeto.integrationtest.domain; public class OrderNotFoundException extends RuntimeException { public OrderNotFoundException(String id) { super("Order not found with id: " + id); } }
E agora vamos refatorar nosso método GET para gerar esse nossa exception:
@GetMapping("/{id}") public OrderCreatedDto getOrder(@PathVariable String id) { final UUID uuid = UUID.fromString(id); final Order order = this.repository.findById(uuid).orElseThrow(() -> new OrderNotFoundException(id)); return OrderCreatedDto.from(order); }
Legal, mas isso não irá resolver todos os nosso problemas, só mudamos o sabor do nosso erro. Agora iremos fazer o nossa aplicação interpretar que toda vez que essa exceção for gerada, nós iremos captura-la e gerar uma saída personalizada com o formato que desejamos. Para isso iremos criar uma nova classe para gerar essa configuração. Criaremos uma nova classe em com/seuprojeto/integration/app:
package com.seuprojeto.integrationtest.app.controller; import com.seuprojeto.integrationtest.domain.OrderNotFoundException; import org.springframework.http.HttpStatus; import org.springframework.web.bind.annotation.ExceptionHandler; import org.springframework.web.bind.annotation.ResponseStatus; import org.springframework.web.bind.annotation.RestControllerAdvice; import java.util.Map; @RestControllerAdvice public class HandlerException { @ExceptionHandler(OrderNotFoundException.class) @ResponseStatus(code = HttpStatus.NOT_FOUND) public Map handleOrderNotFoundException(OrderNotFoundException e) { return Map.of("message", e.getMessage()); } @ExceptionHandler(Exception.class) @ResponseStatus(code = HttpStatus.INTERNAL_SERVER_ERROR) public Map handleException(Exception e) { System.out.println(e.getMessage()); return Map.of("message", "Internal server error"); } }
Esta classe irá capturar nossas exceções, vamos começar falando do método:
public Map
Este método irá fazer com o nosso framework capture quando uma exceção é gerada. Especificamente este método irá capturar qualquer exceção que ocorra e olhando mais atentamente vemos que irá retornar uma mensagem padrão com o seguinte formato:
{ "message": "Internal server error" }
Aqui teremos um StatusCode 500. É uma boa prática este método pois isso evita que toda a stack da exception seja retornada ao usuário final que fez seja lá chamada para nosso aplicação, evitando expor detalhes técnicos da aplicação. Veja que antes do retorno “logamos”(Não necessariamente o estado da arte de logs de aplicação, certo?) a mensagem de erro original para facilitar possíveis investigações posteriores.
Porém este método é bastante genérico e não trata diretamente da nosso necessidade que é tratar nossa exceção personalizada OrderNotFoundException, por isso criamos um método específico para capturar e tratar nossa exception:
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
