단위 테스트까지는 오케이. 비즈니스 로직 검증할 때 필요하다고 생각하고 있고, 단위테스트 프레임워크도 꾸준히 사용함
(다만 요즘 공부중인 방식으로는 잘 안썼고, 서비스 로직이 너무 길 때나 알고리즘 요구할 때 검증용도로)
최근에 단위테스트 관련 공부하면서 실무에 적용 중인데,
제안하는 방법대로 죄다 인터페이스로 감싸고 있으니 쓸모없는 코드가 너무 많이 늘어남
목 객체 만들면 결과값 없이 호출동작만 검증이 가능하기는 해서 '테스트 코드'가 단순해진다는 장점은 있는데,
결론이 좀 이상한거 아닌가?
테스트코드를 위해서 멀쩡한 객체를 인터페이스로 감싸고 실행코드를 복잡하고 디버깅이 어렵게 만들어야 하다니..
굉장히 고민을 많이 하고 있는 주제인데, 인터페이스 없이 인메모리 db를 쓰거나 sqlite를 써서 검증하는 방법이 오히려 공수가 더 적게 들어간다
유닛테스트를 위해 프러덕션 코드가 복잡해지고 디버깅이 어려워지면 주객전도 느낌이 나긴해. 그래서 난 유닛테스트는 할만한 것만 하고 커버리지에 집착안함
할만한 것의 경계선은 의존성이 없거나 정말 간단하게 주입할 수 있는 애들까지만 대상으로 삼고 그 이상은 유닛테스트 대상이 아니라고 봄. 너무 생산성이 떨어짐
이렇게 하면 불필요한 인터페이스 싹다 쳐낼 수 있고, 실제 프러덕션에 돌아가는 코드를 대상으로 테스트 가능함
꼭 필요한 곳에다만 하는 편임