작성
·
86
0
안녕하세요! 소프트웨어의 안정성과 테스트에 대해서 많은 고민을 가지고 있는 주니어 백엔드 개발자입니다.
우빈님의 강의로 실용적인 테스팅 방식에 대해서 기반을 다졌습니다. 덕분에 면접 질문에서도 우빈님의 의견과 저의 의견이 합쳐져서 좋은 답변을 할 수 있었어요!
취업 이후에도 여러가지 테스트 서적을 읽으면서 다른 관점도 많이 바라보고 있는데요. 이 과정에서 영속성 계층에서의 테스트와 E2E 테스트 부분에서 해소되지 않은 고민이 있어서 조언을 얻고자 찾아왔습니다.
먼저 영속성 테스트 관련 질문부터 드리고자 합니다.
취업을 하기 전에 취준을 하는 상황에서는 H2 DB로만 해소 할 수 있는 상황이 많았던 것 같습니다.
하지만 실무에 들어오니 생각보다 Native Function을 사용하는 경우가 있고, 버전 문제로 각 DB에 있는 연산자가 제대로 동작하지 않는 일 (Dialect 이슈) 도 적지 않게 볼 수 있었습니다.
이전에 답변 주신 https://www.inflearn.com/community/questions/1408867/classicist-vs-mockist
해당 내용처럼 저 또한 동일하게 영속성 계층에서의 테스트를 DB 관점에서 그냥 동작하겠거니 하고 안일하게 생각하여 제대로 동작하지 않는 케이스를 봤기에 할 필요가 있다고 생각을 하는데요.
아직까지는 제 경험에서는 Test Container를 사용하여 실 상황과 유사한 DB를 사용하는 것이 그나마 합리적인 방법으로 생각을 하고 있습니다. 하지만, 또 컨테이너가 뜨다보니 테스트하는데 걸리는 시간이 상당한 것도 단점으로 다가오기는 하더라구요.
명확한 답은 없겠지만 우빈님은 위와 같은 비슷한 상황에서 어떤 방식을 택하고 계시는지 더 좋은 방법은 없을지하여 질문을 먼저 드리게 되었습니다.
이어서, E2E 테스트 관련 질문입니다.
비즈니스 계층에서의 통합 테스트가 작성이 되었다면 아직까지는 우빈님의 생각과 동일하게 프레젠테이션 영역에서는 통합 테스트를 하지 않아도 괜찮지 않을까? 라는 생각을 가지고 있는데요.
하지만, 종종 테스트 관련 여러 서적이나 토론등을 보면 E2E 테스트는 중요하다는 관점을 가지고 있는 글이나 영상을 종종 찾아 볼 수 있었고, 무엇보다 저희 팀원분들중에서도 "E2E 테스트를 하는게 아니라면 프레젠테이션 레이어를 테스트 할 필요가 있어?" 라는 질문을 받았을 때 다음과 같은 생각이 들었습니다.
"그러네.. 지금까지는 거의 문서화를 목적으로 작성을 했었는데, 문서화를 RestDocs, RestDocs to Swagger(OpenApi Spec) 를 하는게 아니라면 작성 할 필요가 있을까?"
라는 의문이 떠올랐습니다.
혹시 이 부분에 대해서 어떻게 생각하시는지 우빈님의 소견을 듣고 싶어서 긴 글로 질문을 드리게 되었습니다.
항상 좋은 강의 좋은 인사이트 제공 해주셔서 늘 감사드립니다.
답변 1
0
안녕하세요, 종운 님!
먼저 영속성 테스트 관련 질문부터 드리고자 합니다.
취업을 하기 전에 취준을 하는 상황에서는 H2 DB로만 해소 할 수 있는 상황이 많았던 것 같습니다.
하지만 실무에 들어오니 생각보다 Native Function을 사용하는 경우가 있고, 버전 문제로 각 DB에 있는 연산자가 제대로 동작하지 않는 일 (Dialect 이슈) 도 적지 않게 볼 수 있었습니다.아직까지는 제 경험에서는 Test Container를 사용하여 실 상황과 유사한 DB를 사용하는 것이 그나마 합리적인 방법으로 생각을 하고 있습니다. 하지만, 또 컨테이너가 뜨다보니 테스트하는데 걸리는 시간이 상당한 것도 단점으로 다가오기는 하더라구요.
맞습니다. 결론부터 이야기하자면, 저는 도메인마다 취해야 하는 전략이 다르다고 생각해요.
제가 소개드린 H2를 사용한 테스팅 방식은 장점이 명확하고, 대부분의 케이스를 커버할 수 있는 방식이라고 생각해요. (80~90%)
말씀주신 것처럼 특수한 상황에 특정 데이터베이스(ex. MySQL)와의 차이 때문에 테스트가 어려운 상황이 발생할 수도 있는데요.
결국은 Dialect를 사용하지 않는 방향으로 단순화해서 기능을 리팩토링하거나, 도메인 특성상, 혹은 기타 이유로 변경하기 어렵고 반드시 테스트를 진행하는 것이 좋겠다고 생각한다면 속도 문제를 트레이드오프로 가져가면서 TestContainer를 사용하는 것이 맞다고 생각합니다.
일반 케이스를 H2로 테스트하고, 해당 케이스만 별도로 테스팅하는 전략도 취해볼 수 있을 것 같고요.
(팀 내 논의에 따라서는 관련 케이스가 적고 중요도가 낮으면, 자동화된 테스트 말고 필요할 때 수동 테스트를 진행하자, 도 합리적인 결론이 될 수도 있겠죠..ㅎㅎ 그럴 때 수동 테스트를 진행하기 편한 환경을 만드는 것은 또 별개의 (필요한) 이야기이고요.)
이어서, E2E 테스트 관련 질문입니다.
비즈니스 계층에서의 통합 테스트가 작성이 되었다면 아직까지는 우빈님의 생각과 동일하게 프레젠테이션 영역에서는 통합 테스트를 하지 않아도 괜찮지 않을까? 라는 생각을 가지고 있는데요.
하지만, 종종 테스트 관련 여러 서적이나 토론등을 보면 E2E 테스트는 중요하다는 관점을 가지고 있는 글이나 영상을 종종 찾아 볼 수 있었고, 무엇보다 저희 팀원분들중에서도 "E2E 테스트를 하는게 아니라면 프레젠테이션 레이어를 테스트 할 필요가 있어?" 라는 질문을 받았을 때 다음과 같은 생각이 들었습니다.
"그러네.. 지금까지는 거의 문서화를 목적으로 작성을 했었는데, 문서화를 RestDocs, RestDocs to Swagger(OpenApi Spec) 를 하는게 아니라면 작성 할 필요가 있을까?"
라는 의문이 떠올랐습니다.
혹시 이 부분에 대해서 어떻게 생각하시는지 우빈님의 소견을 듣고 싶어서 긴 글로 질문을 드리게 되었습니다.
E2E 테스트, 혹은 인수 테스트도 마찬가지로 저는 도메인에 따라 다르게 취해야 할 전략이라고 생각해요.
예를 들어, Server to Server(S2S)로 다른 서버에 API를 제공하는 도메인이 있다고 한다면, 그리고 API 간 특별히 관계가 없는 독립적인 API를 구성하고 있다면, 서비스 통합 테스트로 대부분의 케이스가 커버될 것이라 기대해볼 수 있겠습니다.
반대로, 프론트엔드와 직접적으로 소통하고, 일반 사용자들이 다이렉트로 이용하게 되는 도메인이라면, E2E, 인수 테스트의 중요도가 굉장히 높을 수 있습니다.
개발 관점을 넘어 사용자 관점에서 여러 케이스에 대한 테스팅이 필요하고, 실제 운영 환경에서의 조건을 최대한 재현하여 검증하는 것이 중요하기 때문입니다.
또 여러 API가 일련의 시나리오를 가지고 순차적으로, 혹은 병렬적으로 호출되는 경우, 해당 시나리오를 기반으로 테스트를 진행하는 것도 필요할 수 있습니다. (1번 API에서 응답을 받고, 그 응답을 가지고 다시 2번 API에 요청하는 등, ex. 회원가입-로그인-마이페이지 접근)
(S2S, C2S와 같이 이분법적으로 나눈 것은 이해를 돕기 위한 예시입니다.)
고로 해당 사항도, 팀 내 논의에 따라 잘 결정하면 되는 사항이라고 생각해요.
도움이 되셨기를 바랍니다.
감사합니다. 🙂
정말 상세한 답변 감사드립니다!
Native Function을 사용하지 않는 테스트는 H2 DB를 사용하여 테스트하고
Native Function을 사용하는 테스트는 테스트 환경을 분리해서 테스트 할 수 있겠네요!
좋은 인사이트를 얻어갑니다!
말씀하신 것처럼 E2E 테스트는 시나리오에 따라 필요한 경우에 진행하면 되겠네요!
감사합니다