테스트는 문서!

• 테스트 코드는 문서로서 사용되어야 한다. 그러므로,

• 테스트 코드를 보고 테스트의 내용과 목표를 이해할 수 있어야 한다.

  • 테스트 코드가 외부의 클래스나 파일 등을 참조해서는 안된다.

  • 테스트 코드의 일부 내용을 @BeforeEach나 @AfterEach로 코드를 분리하거나, 객체 생성을 위한 메서드를 분리할 수 있다. 하지만 부수적인 부분에 한정해야 한다.

     

지금까지 테스트 코드의 중복을 제거하고 추상화 하기 위해 노력했다. 이런 방식보다는 하나의 문서로서 테스트 코드 만으로 충분하게 이해할 수 있는 코드를 만들어봐야겠다!

테스트는 하나하나

• JpaRepository이나 로직이 작은 객체에 대해서도 테스트 코드를 다 작성하자.

• 향후 해당 로직이 어떻게 변경될지 모른다. 일단 작성하고 미래의 변경에 대응하자.

어디서 읽은 글이 있었는데, 프레임워크를 테스트해서는 안된다는 말을 들었다. 그러므로 JpaRepository.findBySomething과 같이 스프링이 제공하는 메서드 네이밍 기반의 코드는 지금까지 테스트하지 않았다. 하지만 언제 @Query로 변경될지 모르는 것도 사실이며, 엔티티의 필드가 변경되면 이에 대응하는 코드가 필요할 수도 있어 보인다. 다음부터는 간단하게라도 사용하는 모든 메서드에 대한 테스트를 작성해보자.

classist vs mockist

• 테스트 코드를 가능하면 운영과 유사하도록 테스트를 작성하는 classist와 테스트에 필요한 객체를 가능한 대역으로 만들어 테스트 자원을 최소화하고 단위 테스트를 수행하는 것을 선호하는 mockist가 있다고 한다.

• https://cl8d.tistory.com/43 글의 ✔  각각의 장단점을 체크해보기 을 보면 실제로 어떻게 다르게 접근하는지 이해하기 쉽게 작성되어 있다.

• 개인적으로는 스프링을 사용하면 전자가 맞다는 생각을 한다. 왜냐하면 H2 등 스프링 차원에서 훌륭하고 가벼운 대역을 제공하기 때문이다. 굳이 given(someRepository.getSomething()).willReturn(new Something())의 형태로 작성하기보다 그냥 H2에서 given에서 실제로 저장하고, then에서 getSomething()으로 가져오면 된다. 이로 인한 코드 분량도 매우 줄어들고 직관적으로 된다고 생각한다.

• 다만 외부 API 등 대역이 불가피하게 필요한 경우 mockist처럼 작성해야 한다고 생각한다. 그렇지 않으면 테스트를 위한 별도의 대역 클래스를 작성해야 하며, 이는 앞서 작성한 테스트는 문서! 의 원칙에 어긋난다.

기타 배우거나 느낀 점

• assertThat().extracting()형태로 테스트 코드를 작성하는 것을 처음 알게 되었다. 실무에서 사용해보니 무척 편해서 자주 애용할 것 같다.

• @DataJpaTest은 @Transactional이 포함되어있고 이로 인하여 비즈니스 로직에서의 누락된 @Transactional이 있는 것처럼 될 수 있음을 알게 되었다. 기본적으로는 @SpringBootTest로 하자.

• 레이어 간 파라미터에 대한 명칭을 어떻게 할지 고민이 많았는데 강의에서 좋은 예제가 있었다.

  • controller : ProductInsertRequest

  • service: ProductInsertServiceRequest

  • repository: Product

  • 다음부터 ServiceRequest란 형태로 나도 써야겠다.