Step3 - 테스트를 통한 코드 보호 #841
Conversation
단위 테스트를 작성하며 필요한 의존관계에 대해 모킹하는것은 자연스러운 과정이라고 생각합니다 😄 SpringBootTest 를 사용한다고 해서 자동으로 롤백을 해주는것이 아닌 @transactional 과 함께 사용하는 경우 롤백이 되는것으로 알고 있습니다 ! |
검증이 순차적으로 라는 의미가 모호한데, table 을 테스트 하기 위해 orderLineItems, menu 가 필요한 상황이라면 테스트를 하기 위한 setup 과정을 거쳐야 합니다 😄 |
mock 객체가 많아짐에 따라 테스트 코드를 작성하는 비용이 높아지는것은 자연스러운 현상입니다. stub 설정과 관련해서는 fake 객체를 작성해보는것도 좋을것 같아요 😄 |
- ParameterizedTest 적용 - MenuGroupTestFixture 적용
| import static org.mockito.BDDMockito.given; | ||
| import static org.mockito.Mockito.verify; | ||
|
|
||
| public class MenuGroupTestFixture { |
There was a problem hiding this comment.
Fixture 를 MenuGroup 만이 아닌 다른 테스트 코드에서도 활용해보세요 😄
별도의 클래스 파일로 분리하면 다른 테스트 코드에서도 사용할수 있습니다.
#841 (comment) 에 남겨드린것 처럼 Fixture를 적극적으로 활용하여 테스트 코드 작성에 대한 리소스를 줄이수 있도록 경험해보세요 !
리뷰 잘 부탁드립니다.
제 테스트 코드를 작성하다 보니 주문 테스트 코드에서 애를 먹었는데 방향성에 대해서 이렇게 검증하는 것이 맞을까요?
Q. Repository 계층까지 모킹하는 것이 맞는지, 실제 DB를 사용하는게 좋은지 궁금합니다.
제가 알기로는 @SpringBootTest 를 사용하면 값을 테스트 이후에 롤백해주는데 실제로 값이 입력되는 부분까지 확인하는 것이 테스트라는 개념에 더 부합하지 않나 싶은데 리뷰어님은 어떻게 생각하시나요?
Q. 여러 계층의 검증이 순차적으로 일어날 때, 테스트는 어떻게 구성하는 게 좋을까요? (orderLineItems -> menu -> table 순서) 와 같은 경우가 궁금합니다.
Q. OrderService와 같은 복잡한 비즈니스 로직을 테스트할 때 전략
Order, Menu, OrderTable 에서 각 케이스 마다 mock 객체와 stub 설정이 많이 필요한게 특히 어려웠습니다. 작성하다 보니 테스트 가독성과 데이터 설정의 중복 사이 에서도 고민이 됩니다.