테스트 하기 쉬운 코드에서 테스트의 범위?

자문 자답 하겠습니다

• 질문에 대한 답은 단위 테스트 인것 같습니다. 단위 테스트를 통해 각 객체간의 책임을 잘 할당하게 되면, 단위 테스트를 작성할 시에, 해당 객체가 가진 책임을 위주로 테스트 코드를 작성할 수 있기에 "객체지향적으로 객체간의 책임과 역할을 잘 분배해서 설계했는지도 같이 검증이 될것 같습니다"

• 그렇다고, 통합 테스트나 인수 테스트가 불필요하다는 것은 아닌것 같습니다. 단위 테스트에서 검증하기 어려운 서비스의 한 기능을 검증하고, 객체 간의 의존성이 잘 연결되어 전체 시스템이 잘 작동하는지를 확인할 필요도 있기에 이후 강의에서 나오는 테스트 피라미드 모형 처럼 작성하는게 좋겠다 라고 생각이 들었습니다

   

안녕하세요. 답변이 늦어 죄송합니다. 커뮤니티에 2달이 넘어간 글들이 쌓여있는 것을 보니 여러모로 민망하고 미안한 마음입니다. 근래에 출판사로부터 좋은 제의를 받아 집필하느라 정신이 없었습니다.

자문자답 해주신 내용 전부 맞는 말입니다. :) 질문을 남기고도 끝까지 고민하셔서 이를 또 본인의 질문에 답으로 달아주시니 감사합니다. 개인적으로 어떤 답이라도 본인만의 결론을 만드는 게 중요하다고 생각하는 데 본받을 만한 것 같습니다. 그래서 아래는 약간의 첨언만 하였습니다.

우선 제가 영상에서 종종 이야기하는 ‘테스트하기 좋은 코드는 잘 설계된 코드일 것이다’라는 말중 테스트하기 좋은 코드 == 테스트하기 쉬운 코드입니다. 그리고 여기서 말하는 테스트하기 쉬운 코드란 사람의 노동이 적게 들어가는 방향이라고 이해해주시면 될 것 같습니다.

• 그렇다면 인수 테스트는 테스트하기 어려운 테스트입니다. 모든 테스트 중에서 가장 노동이 많이 들어가는 방향이기 때문입니다.

• 통합 테스트라는 말은 제가 좋아하질 않아서 이를 중형 테스트라고 이해하고 답변하겠습니다. 중형 테스트는 자동화된 테스트이니 그래도 인수 테스트보다는 조금 더 쉽다고 볼 수 있습니다. 하지만 테스트를 위해 외부 시스템과 연동을 해야 하니 단위 테스트에 비하면 노동이 조금 더 들어가는 방향입니다.

• 단위 테스트는 중형 테스트에 비하면 훨씬 쉬운 테스트입니다. 외부 연동을 하지 않아도 되고 테스트의 속도도 빠르기 때문입니다. 특히 mock과 fake까지 만들어 주지 않아도 된다면 더 좋을 것입니다.

부족하지만 답변이 되었으면 합니다. 감사합니다!