스프링 부트에서 테스트 코스 작성하기

 

https://product.kyobobook.co.kr/detail/S000001019679

스프링 부트와 AWS로 혼자 구현하는 웹 서비스 | 이동욱 - 교보문고

지금 부터 스프링 부트와 AWS로 혼자 구현하는 웹 서비스라는 책을 읽고 따라해가면서 느낀점이나 내용들을 정리해볼려고 한다.

 

테스트 코드

테스트 코드는 요즘 회사에서 신입을 뽑을 때 필수로 생각하는 부분이라고 한다. 

 

TDD

TDD는 테스트가 주도하는 개발을 이야기한다.

• RED : 항상 실패하는 테스트를 먼저 작성한다.
• GREEN : 테스트가 통과하는 프로덕션 코드를 작성한다.
• REFACTOR : 테스트가 통과하면 프로덕션 코드를 리팩토리한다.

 

단위 테스트는 TDD와 다른 말이다.   

TDD의 첫 번째 단계인 기능 단위의 테스트 코드를 작성하는 것이다. 순수하게 테스트 코드만 작성하는 것이다.

이 책에서는 단위 테스트 코드를 설명해주고 있다.

 

빠른 피드백

이 부분을 읽으면서 깜짝 놀랐다. 빠른 피드백이 정확히 내가 이번 프로젝트에서 사용하던 방법이었다.

1. 코드를 작성하고
2. 프로그램을 실행한 뒤
3. Postman으로 API 테스트 도구로 HTTP 요청하고
4. 요청 결과를 눈으로 검증한다
5. 결과가 다르면 다시 프로그램을 중지하고 코드를 수정한다.

정확히 내가 사용했던 방법이다. 

 

테스트 코드의 장점

1. 굳이 손으로 직접 톰캣을 계속 올렸다 내렸다 할 필요가 없다.
2. 테스트 코드를 작성하면 더는 사람이 눈으로 검증하지 않게 자동검증이 가능하다.
3. 개발자가 만든 기능을 안전하게 보호해 준다.

 

테스트 코드를 도와주는 프레임워크

• JUnit - Java
• DBUnit - DB
• CppUnit - C++
• NUnit - .net

나도 이번에 스프링을 배울때 JUnit4를 배웠다.

 

테스트 코드 작성해보기

나는 스프링을 사용해본 경험이 몇번 있어 책 내용을 따라가는 대신 만들 수 있는 부분은 알아서 만들어 봤다.

여기서 안 사실은 일반적으로 패키지명은 웹 사이트 주소의 역순으로 한다고 한다. 

인텔리제이에서 지원해주는 Springboot Initialir로 프로젝트를 만들면 Application 파일이 자동으로 만들어진다.

@SpringBootApplication
public class FreelecSpringboot2WebserviceApplication {
    public static void main(String[] args) {
        SpringApplication.run(FreelecSpringboot2WebserviceApplication.class, args);
    }
}

이 부분이 앞으로 만들 프로젝트의 메인 클래스이다. 

• SpringBootApplication : 스프링 부트의 자동 설정, 스프링 Bean 읽기와 생성을 모두 자동으로 설정된다.
• 또 이 위치부터 설정을 읽어가기 때문에 이 클래스는 항상 프로젝트의 최상단에 위치 해야 한다.
• SpringApplication.run : 내장 WAS를 실행 한다.

내장 WAS란?
별도로 외부에 WAS를 두지 않고 애플리케이션을 실행할 때 내부에서 WAS를 실행하는 것이다.
이렇게 되면 항상 서버에 톰켓을 설치할 필요가 없게 되고, 스프링 부트로 만들어진 Jar 파일로 실행하면 된다.

 

HelloController 만들기

@RestController
public class HelloController {
    @GetMapping("/hello")
    public String hello() {
        return "hello";
    }
}

@RestController

• 컨트롤러를 JSON으로 반환하는 컨트롤러로 만들어 준다.
• 예전에는 @ResponseBody를 각 메소드마다 선언했던 것을 한번에 사용할 수 있게 해준다고 생각하면 된다.

@GetMapping

• HTTP Method인 Get의 요청을 받을 수 있는 API를 만들어 준다.

 

HelloControllerTest 만들기

@RunWith(SpringRunner.class)
@WebMvcTest(controllers = HelloController.class)
public class HelloControllerTest {
    @Autowired private MockMvc mvc;

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

        mvc.perform(get("/hello"))
                .andExpect(status().isOk())
                .andExpect(content().string(hello));
    }

@RunWith(SpringRunner.class)

• 테스트를 진행할 때 JUnit에 내장된 실행자 외에 다른 실행자를 실행시킨다.
• 여기서는 SpringRunner라는 스프링 실행자를 사용한다.
• 스프링 부트 테스트와 JUnit 사이에 연결자 역할을 한다.

@WebMvcTest

• 여러 스프링 테스트 어노테이션 중, Web(Spring MVC)에 집중할 수 있는 어노테이션이다.
• @Controller, @ControllerAdvice 등을 사용할 수 있다.
• @Service, @Component, @Repository 등은 사용할 수 없다.

@Autowired

• 스프링이 관리하는 빈(Bean)을 주입 받습니다.

private MockMvc mvc

• 웹 API를 테스트할 때 사용한다.
• 스프링 MVC 테스트의 시작점이다.
• 이 클래스를 통해 HTTP GET, POST, 등에 대한 API 테스트를 할 수 있다.

mvc.perform(get("/hello"))

• MockMvc를 통해 /hello 주소로 get 요청을 한다.

.andExpect(status().isOk())

• mvc.perform의 결과를 검증한다.
• HTTP Header의 Status를 검증한다.
• 200,404,500 등의 상태를 검증한다.
• 여기선 OK 200인지 아닌지를 검사한다.

.andExpect(content().string(hello))

• 응답 본문의 내용이 "hello"인지 검증한다.

이렇게 나오면 성공한 것이다.

 

롬복 사용해보기

롬복은 Getter와 Setter 와 같은 개발에 편리한 도구들을 지원해준다. 프로젝트를 만들 때 필수적으로 추가하는 내용인 것 같다.

주의할 점은 lombock을 사용하기로 하면 Settings > Build > Compiler > Annotation Processors에 Enable annotation processing을 체크해야 한다.

 

HelloResponseDto

@Getter
@RequiredArgsConstructor
public class HelloResponseDto {
    private final String name;
    private final int amount;
}

보통 Controller로 내용을 받을 때 Dto로 받는다. 

 

@Getter 

• 선언된 모든 필드의 get 메소드를 생성해 준다.

@RequiredArgsConstructor

• 선언된 모든 final 필드가 포함된 생성자를 생성해 준다.
• final이 없는 필드는 생성자에 포함되지 않는다.

 

롬복기능 테스트 해보기

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

        HelloResponseDto dto = new HelloResponseDto(name, amount);
        assertThat(dto.getName()).isEqualTo(name);
        assertThat(dto.getAmount()).isEqualTo(amount);
    }

}

assertThat

• assertj라는 테스트 검증 라이브러리의 검증 메소드이다.
• 검증하고 싶은 대상을 베소드 인자로 받는다.
• 메소드 체이닝이 지원되어 isEqualTo와 같이 메소드를 이어서 사용할 수 있다.

isEqualTo

• assertj의 동등 비교 메소드이다.
• assertThat에 있는 값과 isEqualTo의 값을 비교해서 같을 때만 성공이다.

Junit에 비해 assertj의 장점
CoreMatchers와 달리 추가적으로 라이브러리가 필요하지 않다.
자동완성이 좀 더 확실하게 지원된다.

이제 직접 controller로 실험을 해봐야겠다.

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

@RequestParam

• 외부에서 API로 넘긴 파라미터를 가져오는 어노테이션이다.
• 여기서는 외부에서 name이란 이름으로 넘긴 파라미터를 메소드 파리미터에 저장한다.

@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)));
}

param

• API 테스트할 때 사용될 요청 파라미터를 설정한다.
• String만 허용된다.
• 숫자/날짜 등의 데이터도 등록할 때는 문자열로 변경해야 한다.

jsonPath

• JSON 응답값을 필드별로 검증할 수  있는 메소드이다.
• $를 기준으로 필드명을 명시한다.
• name과 amount를 검증하니 $.name, $.amount로 검증한다.

 

이번 장에서 테스트 코드를 만드는 방법에 대해 배웠다. 원래 하고 있었던 점도 있지만 배운점도 많았다. 앞으로 API에 대한 테스트코드를 철저하게 만들어 봐야겠다.