스프링 테스트 코드 전환기 근황2 (1/2): 어떻게 진행되고 있나?

회사에서 테스트 코드 전환을 시작한지 두 달 정도가 지난 것 같습니다. 연말이기도하고 짧은 기간동안 프로젝트가 어떤 변화를 거쳤고, 어떻게 발전해가고 있는지 정리하면 좋을 것 같아서 글을 남깁니다.

 

두 달간의 회고

테스트 코드 전환은 생각했던 것보다 순항 중이라고 생각합니다. 사내에 테스트 코드를 넣기 시작한 계기와 필요성을 어필할 수 있었던 자리가 있었는데, 대부분 긍정적으로 봐주셔서 너무 감사했습니다. 덕분에 작업하면서 올바른 방향으로 프로젝트가 발전하고 있다고 확신하고 작업할 수 있었던 것 같습니다.

https://kok202.tistory.com/335

스프링 테스트 코드 전환기 근황1 (0/0) 발표 자료

테스트 코드를 넣는 방법은 이전 포스팅에서도 언급했지만, 그대로 진행되고 있습니다. 그리고 어떤 내용은 더 나은 방법을 찾아서 더 괜찮은 방법으로 수정되고 있습니다. 재밌는 것은 현재 저희 프로젝트에 테스트 코드를 넣기 힘들게 만드는 문제라고 생각했던 부분들이, 계속 고민하다보니 오히려 설계상 더 큰 이점을 줄 수 있다는 사실로 변했다는 것입니다. 자세한 내용은 언제 한번 더 다룰 수 있으면 좋겠네요.

요즘 드는 생각은 설계와 구현이 분리가 제대로 되지 않았었기 때문에 테스트 코드가 힘들어진게 아닌가하는 생각도 합니다. 그리고 결국 OOP 와 TDD, DDD 모두 사실 하나의 그림을 보고 이야기하고 있었구나 하는 생각도 들고요.

 

뭘 쓰는지 알고 쓰자

테스트 코드를 추가하려보니 "우리 시스템에 들어가는 테스트 코드 라이브러리의 버전도 모르고 있었구나"라는 생각이 들었습니다. 그래서 시작하기 전에 무슨 버전을 쓰고있는지 확인했습니다. JUnit 을 사용하고 있는데, 알고보니 Spring boot starter test 에 이미 JUnit 과 mockito 가 포함되어 있었습니다. 그래서 불필요한 의존성을 제거하였습니다.

https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-test/2.1.2.RELEASE 

 

페어 프로그래밍

테스트 코드 전환은 저에게 자극을 주신 후배님과 함께 페어 프로그래밍을 하며 진행하고 있습니다. 페어 프로그래밍을 하는 이유는 다음과 같습니다.

1. 저는 프로젝트를 제로 베이스에서부터 개발해온 사람으로서 어느정도 관성에 젖어있을 것이라 판단했기 때문입니다. 일단 제 입으로 전환을 하겠다고 하긴 했는데, 잘못하면 또 관성으로 개발하고 있을 것 같았습니다. 그리고 결국 똑같은 실수를 반복할 것 같았습니다. 이를 방지하기 위함입니다. 

2. "테스트 코드 작성에대한 노하우를 팀 차원에서 같이 쌓아가보자"라는 목표가 있기 때문입니다. 아쉽게도 그룹 안에 정확한 테스트 작성 방법을 알려줄 수 있는 분이 없던 것 같습니다. 그래서 TDD 문화를 정착하기 위해서는 같이 성장하는 방법을 고민해야한다 생각했습니다. 

일단 당장은 후배님과 같이 페어 프로그래밍을 하고 있는데 좀 더 노하우가 생기면 다른 분과도 페어를 이루어서 조금씩 테스트 코드 전환 작업을 같이 해보려 합니다.

* 최근에는 조오오오금 요령이 붙은 것 같기도해서, 이번 스프린트에서는 페어가 아닌 각자 해보는 것에 대해서도 고민 중입니다. 어쨋거나 추가 개발 건에도 집중을 해야하니까요. 대신 최대한 코드 리뷰를 꼼꼼히 하는 방향에 대해 고민하고 있습니다.

 

리팩토링

TDD 를 진행하면서 코드에 의미 변화를 주지않는 간단한 리팩토링을 같이 진행하려 하고 있습니다. 주로하는 리팩토링은 아래와 같습니다.

1. 필드 주입을 하는 Autowired 를 제거하고 final 과 @RequiredArgsConstructor을 이용하여 생성자 주입하는 방식으로 변경하고 있습니다. 사실 저는 "필드 주입이 그렇게까지 나쁜가?"라는 생각이었는데요. 오히려 필드 주입이 가독성이 더 괜찮다까지 생각하는쪽 이었습니다. 이 작업은 후배님의 적극적인 어필로, 최대한 반영하려하고 있습니다. "생성자 주입을 이용하면 패키지 순환 참조도 런타임때 파악이 가능하다"는 이야기에 가장 크게 설득 당했습니다.

2. find와 get메소드를 구분하고 있습니다. 모르시는 분들이 있다면 이 포스팅을 읽어보면 좋을 것 같습니다. https://szymonkrajewski.pl/the-practical-difference-between-findby-and-getby-in-repositories/

The practical difference between "findBy" and "getBy" in repositories

이 리팩토링은 개인 프로젝트를 하면서 겪었던 좋은 경험을 가져온 것입니다. 개인 프로젝트(Crowddeer)를 하면서 find 와 get을 최대한 구분해가면서 썼는데, 개인적으로 큰 도움이 되었던 것 같습니다. 그래서 현재 작업중인 프로젝트에서도 이 규칙을 그대로 가져가면 좋을 것 같아서 반영하고 있습니다.