Test Code 2 - 개선생각과 방향

통합테스트 코드를 작성해본 후, 대부분을 mock으로 처리해놓은 현재 유닛테스트에 대한 의문을 가지고 있던 중,

 

https://tech.inflab.com/20230404-test-code/

테스트 코드를 왜 그리고 어떻게 작성해야 할까?

이 글을 보고 변경해야겠다는 생각을 했다.

현재의 유닛테스트는 함수가 내가 생각한 순서대로 실행되는지를 체크하는 테스트에 가까웠기 때문이다.

 

그리고 위의 글에서 가장 와닿았던 부분이 테스트는 결과를 검증하는 것이라는 점이다.

현재 테스트코드는 함수내에서 내가 정해놓은 로직대로 잘 수행되는지를 테스트하고 있다. 이말은 다시말해 로직이 조금이라도 변경되면 그 테스트는 깨지게되고, 지속적으로 수정이 필요한 코드가 되어버린다는 점이다.

실제 비슷한 경험을 겪고보니 이말이 확 와닿았다.

 

하지만 글에만 나온 예시 코드들을 보고 이제막 테스트코드를 시작한 내가 바로 좋은 코드를 작성하기란 많이 어려웠다..

 

일단 mock데이터 만드는걸 class로 묶어서 만들고 적용해보았다. 하지만 매번 인스턴스를 생성하는 모습을 보고나니 상태관리할게 아니라면 굳이 class로 인스턴스를 만들필요가 있을까 싶었다.

그래서 mock데이터 전부 return함수로 만든 후 객체로 묶어서 사용하는 방식을 채택하고, 그방식을 적용하고 있었다.

 

그렇게 혼자 열심히 테스트코드를 좋은 방향으로 변경하기 위해 궁리하고 노력하면서 수정하고 있었는데, 나는 현재 인프런에서 진행하는 커리어랠리 라는 거에 참여중이며, 미션2인 랠리에 이력서 등록하는게 오늘까지라 부랴부랴 작성해서 올렸다.

그리고 다른 사람들의 이력서는 어떤지 둘러보던 중, 인프런에서 근무했던 분의 이력서를 보게되었는데 위의 글을 작성한 분이라는걸 알게 되었다. 그리고 2023 인프콘에서 테스트코드에 대하여 강연하신게 있다는걸 알게되었다.

 

https://www.youtube.com/watch?v=SngFwF_yRuo

 

이걸 보니 완벽하진 않지만, 내가 고민하던 많은 부분들에 대해서 어느정도 해소가 되었다.

우선 mock의 최소화였다. 내가 컨트롤 할 수 없는 외부 의존적인 부분은 mock으로 대체하지만, DB같은 경우는 통합테스트로 진행한다.

그래서 유닛테스트는 외부의존이 없는것에 대하여 하고, 나머지 의존성이 있는것들은 한번에 묶어서 통합테스트로 처리해버리면 되는것이다.

그럼 이제 DB의 이용률이 올라가게 되는데, 이부분은 매번 DB를 초기화하는게 아니라 트랜젝션을 이용해 롤백시키는 방법을 사용하면 된다.

그리고 나는 DB의 동시사용을 방지하기위해 --runInBand를 사용하여 테스트가 순차적으로 진행되도록 변경했는데, 그것보다는 테스트마다 다른 메모리의 DB를 만들어서 적용해주면 될듯 싶다.

 

위에 나열한 부분들을 적용해 보았고, 이와 관련된 글은 

https://springdream0406.tistory.com/227

Test Code 3 - 개선

에 작성하였다.