패스트캠퍼스 환급 챌린지 27일차 : 9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online 강의 후기

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

https://abit.ly/lisbva

 

테스트 코드 작성 실습 화면

 

 

 

 

패스트캠퍼스의 '9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online' 강의 수강 27일차!
오늘은 커뮤니티 피드 서비스에 회원가입 이메일 인증 테스트 및 기능 구현 작업을 진행하였다.

 

 

ATDD를 할 때, TDD로 세부 구현을 테스트하며 진행하였다.

TDD는 Green 이후에 리팩토링을 진행해도 코드의 안정성이 확보된다는 장점을 가지고 있다.

TDD는 Red(테스트 실패) -> Green (테스트 성공) -> Refactor (리팩토링) 순서로 진행하는데, 그린 상태에서는 이미 기능이 원하는 대로 동작하는 게 보장되기 때문에 안정적으로 리팩토링을 진행할 수 있는 것이다.

이러한 장점을 활용하여 아래처럼 코드를 리팩토링하는 작업을 해보았다.

private static boolean isNotValidEmailString(String email) {
    return !pattern.matcher(email).matches();
}

이메일이 정규식 규칙을 만족하는지 검증하는 과정을 따로 메소드화하였다.

// 기존
if (!pattern.matcher(email).matches()) {
    throw new IllegalArgumentException("email is not valid");
}

// 리팩토링 후
if (isNotValidEmailString(email)) {
    throw new IllegalArgumentException("email is not valid");
}

기존에는 조건문 안에서 바로 Pattern 객체의 메소드를 호출해서 사용하던 것을 아래와 같이 메소드 하나 호출하는 것으로 리팩토링 된 것을 볼 수 있다.

 

 

늘 먼저 기능을 구현한 후에 테스트를 진행했던 경험밖에 없어서 그런지 테스트 주도 개발 방식이 굉장히 신기하게 느껴졌다.

처음에는 테스트를 먼저 작성하면 제대로 기능 구현이 가능할까? 싶었는데 오히려 테스트를 먼저 작성하니, 개발해둔 기능에 억지로 맞춰서 테스트 코드를 작성하게 되는 문제가 사라지고 테스트 코드의 장점을 더 극대화하여 사용할 수 있는 것 같다.