01. 모임 중 든 생각
테스트 커버리지를 높여라?
단순하게 정량적인 테스트 커버리지를 높이기 위해 테스트 코드를 작성해야한다고 설명하면 테스트 코드 작성의 설득력이 떨어진다는 생각이 들었습니다. 금융권 같은 정말 크리티컬한 분야에서는 중요하 의미를 가질것도 같은데 대게의 일반 사용자의 애플리케이션에서는 테스트 커버리지를 100%까지 목표하며 리소스를 투자할 필요는 없는 것 같습니다. 예전에 네비게이션의 거의 모든 메뉴를 클릭해 보고 테스트 커버리지를 측정한 적이 있는데 30% 정도의 커버리지가 나왔던 기억이 납니다. 나머지 70%의 코드를 찾아서 테스트 하면 물론 좋겠지만 노력 대비 얼마의 효과를 얻을 수 있을지 질문해 볼 필요가 있는 것 같습니다. 그러나 테스트는 중요합니다. 테스트를 적당히 하자는 논리로 이 말이 사용되어서도 안된다고 생각합니다. 언제나 우리가 가진 제약(시간, 인력 등)과 요구 안에서 우리가 할 수 있는 최선의 테스트를 하는 것이 중요한 것 같습니다.
서비스에 테스트를 위한 코드?
테스트를 위한 코드가 서비스에 추가되어야 할 필요가 있었던 경험이 있습니다. 통신 모듈에서 제어 메시지에 대해 적절한 응답 메시지가 왔는지 직접 까보기 위해서 였는데요. 후에 생각해보니 제어 메시지에 합당한 응답이 왔는지 테스트하는 것은 우리 코드를 검증하는 것이 아니라 상대방 시스템이 정상적으로 동작하는지 테스트하는 것이 었습니다. 우리는 사실 제어 메시지가 인코딩되어 상대 시스템에 잘 전달되었는지 까지만 확인하면 되었고, 또한 그것과는 독립적으로 응답 메시지를 받는다면 잘 디코딩해서 처리하고 있는지를 확인하면 되었습니다. 제어 메시지에 대한 적절한 응답 메시지가 오는지 확인하는 것은 우리 코드의 단위테스트가 아니라 상대 시스템의 성능 검증이 었습니다. 서비스 코드에 테스트를 위한 코드가 추가되고 있다면 서비스하지 않는 기능을 테스트하고 있는 것은 아닌지 돌아볼 필요가 있는 것 같습니다.
TDD의 효과
TDD에 대한 몇 가지 이야기가 나왔는데 제가 시도하며 경험한 TDD의 효과에 대해 정리해 봅니다. 첫 번째는 테스트 코드를 작성하려면 요구사항을 디테일하게 이해해야 합니다. 어떤 조건에서 어떤 입력을 가했을 때 어떤 결과를 기대하는지 서비스 코드 작성 전에 구체적으로 이해하게 되는 효과가 있었습니다. 두 번째는 테스트를 성공시키는데 필요한 코드 작성에 집중하게 됩니다. 종종 기능과 관련 없거나 과도하게 코드를 작성하는 실수를 하게될 때가 있는데 이런 실수를 방지해 주었습니다. 마지막으로는 코드를 작성하는 즉시 테스트 코드로부터 확실한 피드백을 받을 수 있어서 안정감을 가지고 코드 작성을 이어갈 수 있는 것 같습니다.
02. 기억에 남는 말말말
- 학습 테스트를 실천하는 분들이 계시구나!
- 토비의 스프링 책 2장은 왜 테스트 코드를 작성해야하는지 설명하는데 좋은 레퍼런스가 되는 것 같습니다.
- 테스트 코드가 때때로 문서화의 효과를 주기도 해서 좋습니다.
- JUnit 테스트 메서드는 예전에 public이어야만 햇지만 최신 버전에서는 default 접근 제어자면 충분합니다.
- 의존하는게 많아지면 테스트가 어려워집니다. 테스트가 쉽도록 의존성을 정리하다보면 객체지향 설계의 좋은 원칙을 따르게 되는 경우가 많습니다.
- 테스트가 쉽다고 좋은 설계라고 결코 할 수 없습니다. 그러나 테스트가 어려운데 좋은 설계일 가능성은 낮습니다.
- Test Double / 스턴트 더블 / Fake / Mock / Imposter 새로운 용어
- 테스트 코드도 제품의 일부다.
- 테스트 코드 때문에 서비스 코드가 복잡해 지면 안된다고 생각한다.
- Mock 라이브러리를 쓰고 안쓰고가 문제가 아니다. 이 글은 Mock 라이브러리를 쓰면서 나쁜 설계를 개선할 수 있는 기회를 잃게 되었다는게 요지인 것 같다. Mock 라이브러리 자체가 나쁘다고는 할 수 없다. 적절하게 잘 활용하면 된다.
- Mock 라이브러리들은 성능이슈가 있는 편이다. 오히려 성능을 고민해 보자.
- 뭔가 쓰고 안쓰고 보다는 좋은 설계에 대해 고민해 보자.
- restTemplate 같은 구체적인 기술 의존 객체가 비지니스 로직에 직접 드러나는 것은 좋지 않다고 생각한다. 추상화 계층을 통해 캡슐화하는 것이 좋다고 생각한다.
- 단위 테스트라고 할 때 단위는 여러가지 컨텍스트에서 여러 의미로 받아들여진다. 전체 시스템의 하나의 기능일 수도 있고, 외부 리소스에 독립적으로 테스트할 수 있는 하나의 API 테스트일 수도 있다.
- e2e 테스트의 경우 워낙 비지니스로직이 자주 바뀌어 그냥 수동으로 한다는 회사도 많이 만났다.
- TDD를 하면 내가 코드를 작성하고 테스트를 하기 까지의 Gap을 유연하게 그리고 주도적으로 제어할 수 있다. 대게는 코드 작성 완료 후 즉시 하겠지만 1주일 뒤에 내 뜻대로 할 수도 있다.
- 단위 테스트의 범위를 어느 정도의 코드 크기로 잡을 것인지는 내가 어떤 코드를 확신할 수 없고 불안한지 생각해보고 유연하게 가져갈 수 있다. 경우에 따라서는 private 메서드도 테스트 코드로 테스트할 수도 있다.
- 균등 분활과 경계값이라는 개념이 중요한 것 같다. 랜덤하게 500개의 값을 테스트 하는 것보다 양수, 음수, 0 값 3개를 테스트하는게 나을 수도 있다. (500개 모두 우연히 양수라면?)
