헥사고날 아키텍처 시리즈 7. 테스트

헥사고날 아키텍처의 테스트

 

테스트는 비용이 적고, 유지보수가 쉽고, 빨리 실행되어야 합니다. 그래서 테스트 피라미트가 등장했습니다.

단위 테스트 - 통합 테스트 - 시스템 테스트가 순서대로 있습니다. 단위 테스트는 가장 밑에서 가장 넓은 영역을 차지합니다. 시스템 테스트는 가장 비용이 높은 테스트로서 커버리지의 목표가 통합 테스트와 유닛 테스트보다 좁아야 합니다. 모든 영역의 테스트에서 커버리지를 높게 잡으면 새로운 기능을 만드는 것보다 테스트를 만드는데 더 시간을 쓰게 됩니다. 유닛/통합/시스템 테스트는 각각 클래스/연결된 여러 컴포넌트/모든 컴포넌트를 검증합니다.

단위 테스트

단위 테스트를 수행할 때에는 의존성이 있는 컴포넌트의 동작을 mocking 합니다. 그리고 테스트 대상이 모킹하고 있는 의존 대상와 특정 메서드에서 상호작용을 했는지 확인합니다. 이러한 방법이 틀린 것은 아니지만, 테스트하려 는 메서드의 구조가 변경되면 테스트 코드도 수정해야하는 상황이 됩니다. 현재 상태의 메서드에 너무 맞춤으로 테스트 코드를 작성하면, 작은 수정 사항이 생겼을 때에도 “이 테스트 코드를 수정하거나 빼도 될까?”라는 고민까지 넓게 해야합니다. 그래서 단위 테스트에서도 중요한 핵심만 골라서 테스트해야 합니다.

통합 테스트

웹 계층과 영속성 계층은 통합 테스트로 수행하는게 좋습니다. 웹 계층에서는 @WebMvcTest를 사용해서 요청이 Controller를 통해서 처리되는 모든 과정을 통합해서 확인합니다. 영속성 계층에서는 단순히 adapter의 로직만 검증하는 것이 아니라 실제 데이터베이스에도 매핑이 정상적으로 이루어지는지 확인해야합니다. @DataJpaTest 를 사용해서 스프링에서 제공하는 데이터 관련 모든 빈을 등록합니다. 필요한 경우 @Import를 사용해서 특정 객체까지 테스트 대상에 포함시킵니다. 실제 데이터베이스의 동작을 Mocking 하지 않아야하고 H2 데이터베이스보다는 실제 운영 환경에서 사용할 데이터베이스와 동일한 타입의 데이터베이스를 사용해서 통합해서 확인해야합니다.

운영 버그 회고하기

버그를 100% 없애기 위해서 불필요할만큼 자원을 투입해서 테스트 코드를 작성하면 곤란해집니다. 단위 테스트 부분에서 언급했던 것처럼 너무 불필요한 단위 테스트는 새로운 기능이 추가되는 속도를 늦춥니다. 그렇다면 얼마나 많은 테스트 코드를 작성해야할까요. 마음 편히 운영 배포를 할 수 있는 수준으로 작성하면 된다고 생각합니다.

테스트 코드를 작성하더라도 운영 환경에서 버그가 발견되기 마련입니다. 각 제품의 그리고 각 기능의 담당자들이 모두 자신의 마음이 편할만큼 테스트 코드를 작성했다는 가정하에, 그 다음에 진행되어야 하는 것은 버그에 대한 회고입니다. 배포에 마음이 편할정도로 테스트 코드를 작성했음에도 버그가 발견된 이유가 무엇인지 고민해보는 행위에 대한 중요성이 공유되어야 합니다. 테스트 코드가 없는 레거시 부분에서 버그가 발견되었으면 하나씩 하나씩 테스트 코드를 추가해야겠습니다.

테스트 코드를 작성할 시간이 없다면

기능 개발이 끝난 뒤에 테스트 코드를 추가하느라고 1.5배의 시간이 들어가는 것은 아닌지 고민해봐야합니다. 테스트 코드를 먼저 작성하는 TDD 방식의 효용성과 별개로, 개발과 테스트 코드 작성의 과정을 최대한 하나로 통합해야 합니다. 개발하면서 “아 메서드 파라미터가 이렇게 되어 있으면 테스트 하기에 불편한데”라는 생각을 하면서 개발하는게 좋습니다. 이론적으로 테스트 코드를 작성하면 개발하는 시간이 더 짧아진다고 합니다. 기능 개발만 하는데 드는 시간이 1이라고 할 때, 해당 기능에서 배포 이후에 문제가 발생하면 수정하는데 0.5 다시 배포 프로세스를 수행하는데 0.5가 소요됩니다. 만약 배포 전에 테스트 코드까지 작성했다면 1.5의 비용만 투입했기 때문에, 해당 기능에 소요되는 잠재 시간까지 줄인다는 측면에서 시간이 더 적게 들어간다고 본다고 생각합니다.