개요
본 포스팅은 Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트을 정리한 내용입니다.
1. 테스트란
테스트는 어떤 시스템이 제대로 동작하는 지 검증하는 과정입니다.
테스트는 크게 두 가지로 분류할 수 있습니다.
1.
사람이 직접 사용해보면서 준비된 체크리스트를 체크하는 인수 테스트
2.
테스트 코드를 돌려 결과 값과 예상 값을 비교하는 자동 테스트
자동 테스트 예시는 다음과 같습니다.
@Test
public void 이메일_회원가입을_할_수_있다(){
//Given
UserCreateRequest userCreateRequest = UserCreateRequest.builder()
.email("foo@localhost.com");
.password("123456")
.build();
FakeRegisterEmailSender registerEmailSender = new FakeRegisterEmailSender();
// when
UserService sut = UserService.builder()
.registerEmailSender(registerEmailSender)
.userRepository(userRepository)
.build();
sut.register(userCreateRequest);
// then
User user = userRepository.getByEmail("foo@localhost.com");
assertThat(user.isPending()).isTrue();
assertThat(registerEmailSender.findLatestMessage("foo@localhost.com").isPresent()).isTrue();
assertThat(registerEmailSender.findLatestMessage("food@localhost.com").get()).isEqaulTo("~~");
}
Java
복사
2. TDD란
TDD는 테스트 주도 개발의 줄임말입니다.
TDD 개발 주기는 다음과 같은데요, 이를 RED, GREEN, YELLOW 라고 부릅니다.
RED는 깨지는 테스트를 먼저 작성하는 것입니다.
과정은 다음과 같습니다.
→ 데이터를 미리 저장해두고, 데이터가 제대로 오는지 확인
→ 그 다음 에러를 던짐
→ 레드 단계에서는 테스트가 실패하는지 제대로 확인
public class PostService {
public PostEntity getPostById(Long id) {
throw new RuntimeException("Method is not implemented.");
}
}
Java
복사
GREEN은 꺠지는 테스트를 성공시키는 것입니다.
과정은 다음과 같습니다.
→ 정상적인 코드를 작성
public class PostService {
public PostEntity getPostById(Long id) {
return postRepository.findById(id)
.orElseThrow(() -> new ResourceNotFoundException("Post", id));
}
}
Java
복사
BLUE는 리팩토링을 하는 것입니다.
단, 복잡한 코드에서는 이 과정이 파괴적일 수 있습니다.
TDD는 이 모든 과정을 프로세스에 적용시킵니다.
3. TDD의 장/단점
장점은 다음과 같습니다.
개발자가 저지르는 다수의 실수가 교정됩니다.
•
깨지는 테스트를 먼저 작성해야 하기 때문에 인터페이스를 먼저 만드는 것이 강제
•
RED 단계에서는 일단 컴파일 되는 코드를 만들기 때문에, 인터페이스를 만드는 것에 집중
•
객체들이 어떤 책임을 지고, 어떤 객체는 어디까지 책임을 져야 하는지 확인
•
인터페이스에 집중한다는 것은 객체지향의 핵심 원리 중 하나인 행동에 집중하는 것
WHAT/WHO 사이클을 고민하게 해준다.
WHAT/WHO 사이클이라는 용어가 의미하는 것은 객체 사이의 협력 관계를 설계하기 위해서는 먼저 어떤 행위를 수행할 것인지를 결정한 후에 누가 그 행위를 수행할 것인지를 결정해야 한다는 것이다. 여기서 어떤 행위가 바로 메세지이다.
또한, 장기적인 관점에서 개발 비용 감소합니다.
단점은 다음과 같습니다.
•
난이도가 매우 높습니다.
•
잘못된 TDD는 개발 속도를 더디게 만듭니다.