Open sootudio opened 4 months ago
통합 테스트 - 원래부터 DB와 관련이 있기 때문에 통합 테스트를 할 수 밖에 없음.
UserService를 Mocking 해서 예외를 터뜨리커나 터뜨리지 않을 때, 트랜잭션의 상태(롤백/커밋) 인지를 테스트 -> 메소드가 몇 번 호출되었는지를 확인하는 방식으로....
UserService를 잘 호출하는지만 확인하면 됨.(UserServiceImpl 단위가 충분히 단위 테스트가 되었다고 가정했을때)
스프링에서 제공하는 트랜잭션 관리자 클래스는 그 자체로 이미 잘 테스트 되어있다고 가정, 우리는 Tx를 테스트할 때 트랜잭션 클래스를 모킹하여 commit, rollback이 잘 호출되는지만 검증
추가로 UserService도 단위 테스트 해두었으므로 모킹하여 예외가 발생하는 경우, 발생하지 않는 경우의 상태를 반환하도록 하기
6.1장부터 UserService를 인터페이스로 만들고 비즈니스 로직를 UserServiceImpl에, 트랜잭션 코드를 UserServiceTx에 넣었습니다.
그리고 6.2장에서 여러 의존관계를 가지거나 DB와 함께 동작해야 하는 테스트는 작성하기 힘든 테스트이고, 때문에 UserServiceImpl은 이미 완벽하게 고립되어 있는 테스트 대상으로 만들 수 있다고 나와 있습니다.
그런데, UserServiceTx는 UserService가 구현한 다른 오브젝트(UserServiceImpl)를 DI 바고, 해당 오브젝트에 모든 기능을 위임하므로 고립되어 있지도 않고, DB와도 연결되어 있으니까 테스트하기 힘든 코드인가? 라는 생각이 들었습니다.
맞다면, 이것에 대한 특별한 언급이 없는 이유는 UserServiceImpl이 비즈니스 로직을 관리하는 핵심적인 코드이기 때문에, 이것을 고립시킬 때 필연적으로 생기는 UserServiceTx 같은 오브젝트의 테스트는 어쩔 수 없는 것인지, 아니면 다른 해결 방식이 있는지 궁금합니다.