스프링 부트: 테스트 코드 작성, 간단한 어노테이션 기능 정리, 롬복

TDD(Test Driven Development)

• 테스트가 주도하는 개발을 뜻함
• 견고한 서비스를 만들 수 있음
• 개발 시간이 길어질 수 있음
• 테스트 코드를 먼저 작성하는 것부터 시작

1. RED: 항상 실패하는 테스트를 먼저 작성
2. GREEN: 테스트가 통화하는 프로덕션 코드 작성
3. REFACTOR: 테스트가 통과하면 프로덕션 코드를 리펙토링

 

 

단위 테스트(Unit Test)

• TDD의 첫 번째 단계인 기능 단위의 테스트 코드를 작성하는 것을 뜻함
• 테스트 코드를 꼭 먼저 작성할 필요가 없음
• 순수하게 테스트 코드만 작성하는 것을 의미

TDD 참고: https://repo.yona.io/doortts/blog/issue/1

 

단위 테스트 코드 작성의 이점

• 개발 초기단계에 문제를 발견할 수 있도록 도와줌
• 코드 리펙토링 및 라이브러리 업그레이드 시 기존 기능이 올바르게 작동하는지 확인 가능(회귀 테스트)
• 기능에 대한 불확실성을 감소시킴
• 단위 테스트 자체가 시스템에 대한 실제 문서로 사용될 수 있음
• 하나의 기능을 추가 시 다른 기능에 문제가 발생할 수 있음 -> 단위 테스트를 통해 모든 기능이 잘 작동하는지 확인

 

테스트 코드가 없을 때

코드작성 -> 프로그램 실행 -> API 테스트 도구로 HTTP 요청 -> 요청 결과를 눈으로 검증 -> 잘못된 결과가 출력되면 프로그램 중지 및 코드 수정

순으로 개발에 대한 검증을 하지만, 테스트 코드를 작성한다면 이러한 수동 작업 없이 자동 검증이 가능

 

 

XUnit

• 개발환경(X)에 따라 Unit 테스트를 도와주는 프레임워크
• Java -> JUnit, DB -> DBUnit, C++ -> CPUnit, .net -> NUnit 등

 

 

스프링 부트 프로젝트: 메인 클레스

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

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

- @SpringBootApplication

• 스프링 부트의 자동 설정. Bean 읽기 및 생성을 자동으로 설정.
• 이 어노테이션의 위치부터 설정을 읽어감 -> 항상 프로젝트 최상단에 위치해야 함

- SpringApplication.run

• 내장 WAS를 실행

- 내장 WAS?

• 별도로 외부에 WAS를 두지 않고 애플리케이션을 실행할 때 내부에서 WAS를 실행
• 스프링 부트로 만들어진 Jar 파일로 WAS 실행(서버에 톰캣을 설치하지 않아도 됨)
• 언제 어디서나 같은 환경에서 스프링 부트 배포를 가능하게 함
• 스프링 부트 권장 사항임
• 대표적인 WAS인 톰캣 또한 서블릿으로 이루어진 자바 애플리케이션이기 때문에, 내장 WAS를 사용할 때의 성능 저하를 크게 고려하지 않아도 됨

 

+ 컨트롤러 쪽에서

- @RestController

• JSON을 반환하는 컨트롤러에 사용
• 예전에 @ResponseBody 어노테이션을 각 메소드마다 선언했던 것을 한번에 사용할 수 있게 해줌

-@GetMapping

• HTTP GET 요청을 받는 API 작성 시 사용
• 에전에는 @RequestMapping(method = RequestMethod.GET) 으로 사용

- @RequestParam

• 외부에서 API로 넘긴 파라미터를 가져옴

 

 

JUnit 테스트 코드 작성(JUnit5 기준)

• 테스트 클래스 명은 '대상 클래스 이름 + Test' 로 작성하는것이 일반적
• 테스트 코드를 작성하고 수동으로 검증하는 습관을 들이는 것이 좋음

 

@ExtendWith(SpringExtension.class)	테스트 진행 시 JUnit에 내장된 실행자 외에 다른 실행자 실행 SpringExtension이라는 스프링 실행자를 사용한다는 의미 스프링 부트 테스트와 JUnit 사이의 연결자 역할
@WebMvcTest	Web(Spring MVC)에 집중할 수 있는 어노테이션 선언 시 @Controller, @ControllerAdvice 등 사용 가능 @Service, @Repository, @Component 등은 사용 불가
@Autowired	스프링이 관리하는 빈을 주입
@AfterExtension	단위 테스트가 끝날 때마다 수행되는 메소드 지정 보통 전체 테스트 수행 시 테스트간 데이터 침범을 막기 위해 사용
@SpringBootTest	별다른 설정이 없다면 H2 데이터베이스 자동 실행 JPA 기능까지 테스트해야 한다면 @SpringBootTest와 TestRestTemplate 사용
MockMvc mvc (import org.springframework.boot.test.autoconfigure.web.servlet.webMvcTest)	웹 API 테스트를 위해 사용 스프링 MVC 테스트의 시작점 GET, POST 등에 대한 API 테스트 가능 JPA 기능은 테스트할 수 없음(@SpringBootTest 사용)
mvc.perform(get("/hello"))	MockMvc를 통해 /hello 주소로 GET 요청을 함
.param	API 테스트 시 사용될 요청 파라미터 설정 String 값만 허용
.andExpect(status().isOK())	HTTP Header의 Status를 검증 OK(200)인지 아닌지 검증
.andExpect(content().string(hello))	응답 본문의 내용이 "hello"인지 검증(컨트롤러에서 리턴하는 실제 내용을 검증)
jsonPath	JSON 응답값을 필드별로 검증할 수 있는 메소드 '$'를 기준으로 필드 명을 명시 ex) name이라는 필드를 검증한다면 $.name 으로 검증해야 함
assertThat (import static org.assertj.core.api.Assertions.assertThat)	assert라는 테스트 검증 라이브러리의 검증 메소드 검증하고 싶은 대상을 메소드 인자로 받음 메소드 체이닝: isEqualTo 등의 메소드를 이어서 사용 가능
isEqualTo	assertj의 동등 비교 메소드 assertThat에 있는 값과 isEqualTo의 값이 같다면 테스트 성공

참고: assertJ가 JUnit의 assertThat보다 편리한 이유 - 백기선

 

 

롬복

• Getter, Setter, 기본 생성자, toString 등을 어노테이션으로 자동 생성해줌
• build.gradle에 의존성 추가 후 플러그인을 설치해서 사용하면 됨

@Getter, @Setter	선언된 모든 필드의 get, set 메소드를 설정해 줌
@RequiredArgsConstructor	final이 붙은 모든 필드를 포함한 생성자를 생성해 줌
@NoArgsConstructor	기본 생성자를 생성해 줌
@Builder	해당 클래스의 빌더 패턴 클래스 생성 생성자 상단에 선언 시 생성자에 포함된 필드만 빌더에 포함