Spring

[Spring] - 롬복 알아보기 및 설치하기

코린이 파닥거리기 2025. 2. 4. 14:56
728x90
반응형
SMALL

자바 개발자들의 필수 라이브러리 롬복을 알아보자.

※롬복은 자바 개발할 때 자주 사용하는 코드 Getter, Setter, 기본생성자, toString등을 어노테이션으로 자동생성해 주는 라이브러리이다. 

롬복 의존성 다운 및 plugins 설치하기

먼저 build.gradle에

밑줄 그어진 부분이 롬복 의존성 설치 코드

다음과 같은 코드를 추가한다. 그 후 Gradle에 들어가서 Refresh로 새로고침해서 의존성을 내려받는다.

그 후 ctrl+shift+A 단축키로 Action실행하여 plugin 설치 팝업으로 들어간다.

그 후 Marketplace 탭에서 lombok을 검색하여 설치한다.

설치가 다 되면 인텔리제이를 재시작한다. 

재시작 하면 인텔리제이 File -> Settings -> Build,Execution,Deployment -> Compiler -> Annotation Processors탭으로 들어가서 Enable annotation processing을 체크한다. 

그럼 이 프로젝트에서는 롬복 사용할 준비가 끝났다.

 

롬복으로 기존코드 리팩토링 하기

기존 코들를 롬복을 리팩토링 해보겠다.

만약 프로젝트가 지금처럼 작은 규모가 아닌 큰 규모 프로젝트였으면 롬복으로 전환이 쉽지 않았을 것이다. 어떤기능이 작동 될지 안될지 예측 할 수 없기 때문이다. 

하지만 우리는 테스트코드를 작성하였기 때문에 롬복으로 변경하고 문제가 생기는지 테스트 코드만 돌려보면 알 수 있다. 

 

web 패키지에 dto 패키지를 추가한다.

앞으로 모든 응답 Dto는 dto패키지 안에 생성하겠다.

 

이제 HelloResponseDto 코드를 작성해보자

package com.jojoldu.book.springboot.web.dto;

import lombok.Getter;
import lombok.RequiredArgsConstructor;

@Getter //선언된 모든 필드의 get메소드를 생성해준다.
@RequiredArgsConstructor//선언된 모든 final 필드가 포함된 생성자를 생성해 준다.
//final이 없는 필드는 생성자에 포함되지 않는다.
public class HelloResponseDto {
    private final String name;
    private final int amount;
}
  • @Getter : 선언된 모든 필드의 get 메소드를 생성해 준다.
  • @RequiredArgsConstructor: 선언된 모든 final 필드가 포함된 생성자를 생성해 준다. final이 없는 필드는 생성자 포함x

롬복 작동 테스트코드 작성

이 dto에 적용된 롬복이 잘 작동하는지 간단한 테스트 코드를 작성해보겠다.

package com.jojoldu.book.springboot.web.dto;
import static org.assertj.core.api.Assertions.assertThat;

import org.junit.Test;

public class HelloResponseDtoTest {

    @Test
    public void 롬복_기능_테스트(){
        //given
        String name = "test";
        int amount = 1000;

        //When
        HelloResponseDto dto = new HelloResponseDto(name,amount);

        //then
        assertThat(dto.getName()).isEqualTo(name);
        assertThat(dto.getAmount()).isEqualTo(amount);
    }
}

HelloResponseDtoTest클래스 코드이다.

 

  • assertThat: assertj라는 테스트 검증 라이브러리의 검증 메소드이다.
  • isEqualTo: assertj의 동등 비교 메소드이다. assertThat에 있는 값과 isEqualTo의 값이 같을때만 성공이다.

※Junit의 기본 assertThat이 아닌 assertj의 assertThat을 사용하는 이유

  • CoreMatchers와 달리 추가적으로 라이브러리가 필요하지 않다.

         Junit의 assertThat을 사용하게되면 is()와 같이 CoreMatchers 라이브러리가 필요하기 때문

  • 자동완성이 좀 더 확실하게 지원된다.

        IDE에서 CoreMatchers와 같은 Matcher 라이브러리의 자동완성 지원이 약하다.

테스트 코드를 실행해보면

정상적으로 기능이 수행되는것을 확인할 수 있다.

롬복의 @Getter로 get메소드가, @RequriedArgsConstructor로 생성자가 자동으로 생성되는 것이 증명되었다.

HelloController에도 ResponseDto API추가하기

그럼 HelloController에도 새로 만든 ResponseDto를 사용하도록 코드를 추가해보자

    @GetMapping("/hello/dto")
    public HelloResponseDto helloDto(@RequestParam("name") String name, @RequestParam("amount") int amount){
        return new HelloResponseDto(name, amount);
    }

기존 HelloController코드에서 위 코드를 추가한다.

그럼 클라이언트가 /hello/dto의 경로로 데이터 요청을 보내면

return new HelloResponseDto(name, amount);

서버는 위 코드를 JSON형식으로 반환한다.

 

@RequestParam: 외부에서 API로 넘긴 파라미터를 가져오는 어노테이션 name(@RequestParam("name"))이란 이름으로 넘긴 파라미터를 메소드 파라미터 name(String name)에 저장하게 된다.

추가된 API 테스트 하기

여기서 name과 amount는 API를 호출하는 곳에서 넘겨준 값들이다. 추가된 API를 테스트하는 코드를 HelloControllerTest에 추가한다.

    @Test
    public void helloDto가_리턴된다() throws Exception{
        String name = "hello";
        int amount = 1000;

        mvc.perform(get("/hello/dto")
                .param("name",name)
                .param("amount",String.valueOf(amount))).andExpect(status().isOk())
                .andExpect(jsonPath("$.name", is(name)))
                .andExpect(jsonPath("$.amount", is(amount)));
    }
  • jsonPath: JSON응답값을 필드별로 검증할 수 있는 메소드이다. $심볼을 기준으로 필드명을 암시한다.                      여기서는 name과 amount를 검증하는 $.name , $.amount로 검증한다.

실행하면 JSON이 리턴되는 API역시 정상적으로 테스트가 통과하는 것을 확인할 수 있다.

 

[출처] - 스프링 부트와 AWS로 혼자 구현하는 웹 서비스

728x90
반응형
LIST