테스트를 도입하면서 느낀점과 고민들

2024.07.19 - [개발/SPRING] - Kotlin + SpringBoot 서버에 테스트 도입기. Kotest와 MockK

 

이전 포스팅에서 테스트는 왜 필요하고, 어떤 것들이 있는지에 대해 정리해봤다.

 

그리고 현재 프로젝트에서 어떻게 쓰면 좋을지도 결정했었다.

 

이 후 한동안 실제로 테스트를 구현하면서, 어떻게 테스트를 서비스에 잘 녹일 수 있을지 고민하면서 구현했다.

 

테스트가 있긴 있었지만, 레거시의 레거시를 테스트하는 용도라 싹 들어내고 다시 구현했다.

 

1. 테스트는 기능을 테스트하는 용도도 크지만 히스토리 용도도 크다

테스트는 사이드 이펙트를 잡는 용도도 크지만 이 코드가 왜 만들어졌는가를 남기는 요소도 포함하고 있다.

 

주석도 서비스 로직에 남겨져 있는 것보다, 테스트에 남기는게 최신화 하기 쉽다.

 

여러 곳에서 주석을 남기지 말라고 하는 이유는 주석이 최신화 되지 않았을 때의 악영향이 크기 때문이었다.

 

특정 서비스 정책 상 들어간 예외 같은걸 테스트로 만들어두면 나중에 봤을 때 이해하기 쉬웠다.

 

2. 테스트를 어디까지 만들지에 대한 범위를 정하기가 어렵다.

사람마다 테스트가 필요한 부분이라고 느끼는게 너무나 달랐다.

 

실장님 테스트의 필요도는 알고 계셨지만, 피쳐 개발 기간에 영향이 가는걸 원치 않으셨다.

 

다른 개발자는 속도감 있는 테스트를 원해서 통합 테스트는 최소화하고 싶어했다.

 

다른 분은 테스트 구현 자체를 귀찮아해서 최종 응답만 검증하는 통합 테스트만 만들고 싶어했다.

 

그래서 컨벤션을 정하기까지 꽤 많은 시간이 필요했다.

 

3. 레거시 코드의 테스트는 응답만 체크하는걸로 하는게 좋다.

레거시 코드에 대한 테스트는 모두가 비슷한 고민이 있는 것 같다.

https://techblog.woowahan.com/2613/

 

첫번째 이유는 리팩토링의 여지가 있기 때문이다.

 

리팩토링은 서버에서 야금야금 진행하고 있기 때문에, FE에 영향이 가면 안된다. 그래서 응답값이 반드시 유지되어야한다.

 

두번째 이유는 레거시 코드 분석에 지나친 시간이 소모될 수 있기 때문이다.

 

레거시 코드의 모든 어려움은 외주 개발이 맡겨 놓은 무성의하고 품질 낮은 코드에서 온다.

 

이 코드를 뜯어보다보면 오류가 발견되는 경우도 있고, 분석 자체도 오래 걸린다. 캡슐화? 객체지향? 주석? 다없다.

 

모킹도 어려웠기 때문에  dev 환경에서 실제로 한사이클을 도는 형식의 응답만 확인하는 통합 테스트로 구성했다.

 

4. 테스트에서의 @Transactional?

https://jojoldu.tistory.com/761

 

향로님 의견 : 트랜잭션을 관리하는 코드에서 또 사용하면 예상치 못한 문제가 발생할 수 있다. 사용하지 않는걸 권장하고 팀에서 실수하지 않게 룰을 잘 정해야 한다. 명시적 초기화 방식을 만들어두고 사용한다.

 

토비님 의견 : @Transactional 메인으로 사용하고 롤백 테스트는 필요하다고 생각할때만 쓴다. 

 

테스트를 도입하면서 @Transactional에 대해 이런저런 고민을 했지만 두 분다 맞는 말을 하고 있다는 생각이 들었다.

 

결국 팀에서 정하는 방식에 따라가야하고, 좋은 룰을 짜야한다.

 

아직 향로님이 제시한 문제는 겪어보지 못해서 @Transactional을 메인으로 사용하면서 작업할 것 같다.

 

5. CI 구성도 잘 생각해야 한다.

Github Actions를 사용하는 현재 프로젝트에서는 어떤 CI를 사용할까에 대한 큰 고민을 안할 수 있었다.

(프로젝트의 규모에 따라 Github를 쓰지만 CI 툴은 달라야 할 수 도 있다)

 

그리고 Github Actions에서 가이드를 잘 해줘서 더 편하게 작업할 수 있었다.

https://docs.github.com/ko/actions/use-cases-and-examples/building-and-testing/building-and-testing-java-with-gradle

 

주의할 점은 Github Actions VM에서 테스트가 돌기 때문에 env 설정들을 잘 맞춰줘야한는 것이다.

 

또, 규모가 있는 프로젝트에서는 더 많은 고민을 해야한다.

 

Github Actions도 사용량 제한이 있기 때문에 지나친 자원을 소모해버린다면,

https://docs.github.com/ko/actions/administering-github-actions/usage-limits-billing-and-administration

 

비용이 너무 커져버리는 배보다 배꼽이 커지는 현상이 발생할 수 있다.

 

데일리 빌드 테스트, 배포 전 테스트, PR 테스트 등 테스트나 목적을 고려해서 적절한 곳에 위치와 횟수를 지정해야 한다.

 

다행히 현재 프로젝트에서는 배보다 배꼽인 큰 일은 발생하지 않아서 다행이었다.

 

마치며

오랜만에 이런 저런 고민을 하면서 코드를 짤 수 있어서 재미있었다.

 

그리고 @Transactional을 테스트에 어떻게 적용하면 좋을까라는 생각도 많이 했다.

 

가장 힘든건 레거시 코드들이언쓴데, 레거시 코드를 볼 때는 화가 나는걸 참을 수 없었다.

 

매번 사이드 이펙트를 발생시키는 부분들이 있는데, 이 부분을 특히 신경써서 나름대로 확실히 테스트하도록 구현했다.

 

그런데 대부분 레거시코드들이라 리팩토링이 먼저였지 않았을까라는 생각이 들긴했다...