Skip to content

Latest commit

 

History

History
34 lines (24 loc) · 5.95 KB

10.md

File metadata and controls

34 lines (24 loc) · 5.95 KB

test code 를 작성하는 본인만의 기준이 있습니까? test 실행 속도를 높이려면 어떤 방법이 좋을까요?

로마

테스트 코드를 작성하는 본인만의 기준이 있습니까?

  • 일단 저는 우리 비즈니스를 수행함에 있어 관여하는 대부분의 로직에 테스트 코드를 작성하려합니다. 테스트 코드를 작성함으로써 추가적인 코드의 변경이 생기더라도 테스트 코드가 깨지는 부분을 수정하면 되기 때문에 리팩토링을 함에 있어 주저함이 적어져 코드 퀄리티를 향상시킬 수 있고 협업을 하는 다른 사람이 테스트 코드를 보고 레거시 코드를 이해하는데 도움을 주기 때문입니다.
  • 하지만 테스트 커버리지 100%에 너무 집착하지는 않습니다. 코드를 짜다보면 getter, setter, equals와 같이 당연하게 동작하는 코드들, 검증된 외부 라이브러리의 코드들이 등장하게 되는데 저는 이와 같은 것들에 대해서는 테스트 코드를 작성하는 비용에 비해 얻는 효용이 적기 때문에 비즈니스 로직에 집중해서 테스트코드를 작성합니다.

테스트 실행 속도를 높이려면 어떤 방법이 좋을까요?

  • 먼저 테스트의 비용을 생각해보면 E2E 테스트보다는 Integration Test 또는 Unit Test 위주로 테스트를 작성할 수 있을 것 같습니다. E2E 테스트에 가까워 질수록 테스트의 수행 시간은 늘어나고 거치는 계층도 많아지게 됩니다. 또한 고려할 것도 더욱 많아지게 되죠 그렇기 때문에 보다 범용적인 상황에서 쓰이는 테스트를 E2E 또는 Integration Test에서 진행하고 예외적인 케이스나 각각의 객체의 디테일한 검증은 Unit Test 쪽으로 넘기는 것이 좋을 것 같습니다.
  • 다음은 스프링 프레임워크 애플리케이션 위주로 이야기를 해보면 슬라이스 테스트를 적극 활용하는 방법이 있습니다. Spring으로 작성된 코드를 테스트할 때 모든 테스트를 @SpringBootTest 를 이용해 작성하는 경우가 종종 보입니다. 하지만 @SpringBootTest의 경우 classes 애트리뷰트를 재정의하지 않으면 현재 테스트에 사용될 빈 뿐만 아니라 애플리케이션 내의 모든 빈들을 띄우기 때문에 수행 속도가 헌저히 낮아지게 됩니다. 각 계층별로 WebMvcTest, DataJpaTest 등 스프링 부트에서 제공하는 여러 슬라이스 테스트를 활용하면서 필요한 빈만 등록하게 된다면 실행 속도를 높일 수 있습니다.
  • 또한 컨텍스트 캐싱을 적극적으로 활용해야합니다. 스프링 프레임워크 위에서 동작하는 애플리케이션을 테스트할 때 가장 많이 드는 비용이 애플리케이션 컨텍스트를 새로 띄우는 비용입니다. 그렇기에 최대한 하나의 컨텍스트를 여러 테스트에서 공유하도록 해야합니다. 스프링의 TestContext 프레임워크는 activeProfile, contextCustomizer, contextLoader 등 테스트 관련 설정이 같은 테스트에 대해서 컨텍스트를 캐싱하게 되는데 이 컨텍스트 캐싱을 최대한 활용하여 같은 레이어에 대한 테스트들의 설정을 동일하게 맞춰서 테스트를 진행하면 테스트의 성능을 개선할 수 있습니다.
    • DirtiesContext 사용하지 않기
    • DirtiesContext? 말 그대로 컨텍스트를 더럽혀 새로운 컨텍스트를 띄우도록 강제하는 애노테이션입니다.
    • MockBean 사용 주의 ( mockBean의 조합에 따라 설정을 다르게 인식 contextCustomizers 에 포함 ) -> 다른 컨텍스트 생성
  • 그리고 마지막으로 모킹을 적절히 사용하는 것도 테스트의 성능을 개선할 수 있는 방법이라고 생각합니다. IO와 DB 관련 테스트는 IO 작업이 없는 일반적인 자바 코드를 테스트하는 것보다는 오래 걸리게 됩니다. 따라서 이와 같은 부분을 유사하게 동작하는 가짜 DB 혹은 가짜 IO 객체를 만들어 테스트를 진행한다면 테스트의 성능을 개선할 수 있다고 생각합니다.

출처

공식문서 - Spring TestContext Framework 스프링부트 테스트를 위한 의존성과 어노테이션, 애플리케이션 컨택스트 캐싱(@SpringBootTest, @WebMvcTest, @DataJpaTest) Listner를 이용한 테스트 격리 (참신해서 넣음)

질문

  • E2E 테스트와 통합 테스트의 차이는 무엇일까요?

    • 통합 테스트는 말 그대로 통합해서 테스트한다, 유닛 단위가 아닌 보다 둘 이상의 컴포넌트 간의 테스트를 의미합니다. 예로 레포지토리와 서비스를 연결해서 테스트하는 것이 있을 것 같습니다.
    • E2E 테스트는 통합 테스트에 포함된다고 생각합니다. 둘 이상의 컴포넌트를 테스트하기 때문이죠. 하지만 그 범위가 각 엔드포인트 까지 즉, 애플리케이션 전반에 걸쳐 동작한다는 차이가 있을 것 같습니다.
    • 이와 같은 E2E 테스트는 매우 무겁고 관리해야하는 대상도 많아지기 때문에 주로 시나리오를 작성해서 인수 테스트 느낌으로 하는 편입니다.

  • 모킹의 범위를 선택해야한다면 DB도 모킹을 하시겠습니까?

    • 무엇을 테스트하고자하는지에 따라서 다를 것 같습니다. 만일 실제 DB에 접근해서 해당 데이터가 올바로 저장되는 과정까지 확인하고 싶다면 데이터베이스 모킹을 하지 않고 테스트용 DB를 설정하여 테스팅할 것 같고 만일 데이터베이스의 동작보다는 서비스에서의 흐름을 테스트하고 싶다면 실제 DB를 사용하기보다는 모킹하여 사용하여 테스트 성능을 올리고 테스트 관심사에 집중할 수 있다고 생각합니다.