680

[utterances-bot]

3. 테스트하기 좋은 코드 - 외부에 의존하는 코드 개선

지난 시간에 테스트하기 좋은 코드에 대해 이야기를 나눴다. (1) 테스트하기 어려운 코드 (2) 제어할 수 없는 코드 개선 이번 편에서는 테스트하기 어려운 코드를 개선하는 2번째 방법인 외부에 의존하는 코드를..

https://jojoldu.tistory.com/680

[par333k]

연재 해주신 시리즈 덕분에 적절한 테스트 코드를 짜는데 큰 도움이 되었습니다. 감사합니다.

[mystyle2006]

내용 중에 궁금한게 있는데 만약 active record 패턴을 사용하지 않고 data mapper를 활용하면 실제 서비스 계층에서는 아래와 같은 코드가 작성되는게 맞을까요?

// service const order = this.orderRepository.findById(orderId); const cancelResult = this.orderRepository.cancel(order); await this.orderRepository.save(cancelOrder)

[jojoldu]

@mystyle2006 본문속 내용처럼 this.orderRepository.cancel(order); 가 아니라 order.cancel() 이 되고, 나머지 로직은 작성하신것과 같습니다 :)

[sjquant]

안녕하세요 향로님, 좋은 글 잘 읽었습니다 :) 테스트 코드에 대한 고민을 많이하고 있는 입장에서 이 시리즈가 너무 반갑네요.

질문이 하나 있습니다. 글의 주제와는 약간 다를 수 있는데

"외부 의존성이 필요한 통합 테스트의 범위를 좁혀야 한다."고 하셨는데,

마틴 파울러가 말한 socialable unittest의 관점, 혹은 이규원님이 작성하신 '정말로 테스트 대역이 필요한가'라는 글을 보면 통합 테스트를 줄이는 것이 좋은가 하는 의문점이 있습니다.

db같은 경우에 대역을 사용하지 않고 socialable test 관점에서 상위 모듈을 테스트하게 되면 오히려 가정을 줄인 상태로 테스트를 더 신뢰할 수도 있지 않을까 생각합니다. (물론 txn rollback이나 db초기화 등을 통해 테스트 간의 독립성은 지켜야겠지만요.)

'테스트코드가 느려진다고 느껴지거나, 소프트웨어가 충분히 복잡해지면 socialable test의 테스트를 신뢰하고 코드를 말씀해주시는 방향으로 리팩터링할 수 있지 않을까' 하는 생각이 드는데 이 부분에 대해서는 어떻게 생각하시는지 의견을 구해봅니다.

다시 한 번 좋은 글 감사드립니다. :)

[jojoldu]

@sjquant 님 안녕하세요! 좋은 질문 감사합니다 :) 다만, 말씀하신대로 이 글은 통합 테스트의 범위를 좁히자 인데요. 통합 테스트의 범위를 좁히는 것 == 단위 테스트의 범위를 넓히는 것 을 의미할순있지만 단위 테스트의 범위를 넓히는 것 == 테스트 더블을 더 많이 사용해야하는 것을 의미하진 않습니다.

원글을 보셔서 아시겠지만, 기존 문제가있던 비즈니스 로직에 대한 단위 테스트에 외부의존성, 테스트더블을 모두 사용하지 않고 테스트가 가능하도록 리팩토링 한것입니다 :) 예제로 나온 cancel() 함수의 리팩토링 버전을 보시면 아시겠지만, 기존 코드에서는 DB를 테스트더블을 사용하거나 실제 DB를 사용해야하는 방식이였던 것을 둘다 필요하지 않은 형태로 개선한 형태입니다 :)

제 생각에는 단위 테스트를 많이 사용한다는 것 == 테스트 더블을 많이 사용하는 것과 똑같이 생각하신게 아닐까 싶은데요 :) 둘은 엄연히 다른 의미라고 생각됩니다 :)

(저보다 훨씬 더 고수이신) 규원님의 글도 자세히 읽어보았는데, 테스트 더블에 대한 문제점을 언급하신 것이지, 단위 테스트가 많아지는 것에 대한 문제점을 언급하신것은 아닌것 같습니다 ^^;

만약 단위 테스트 보다 통합 테스트의 비중을 더 늘려야하는게 아니냐의 의견이라면, 같이 언급해주신 마틴파울러의 테스트 피라미드 번역글이 있으니 이 글도 같이 보셔도 좋을것 같습니다 :)

• https://blog.voidmainvoid.net/451

[sjquant]

@jojoldu 감사합니다. 제가 유닛테스트와 더블을 조금 같은 관점에서 보고 접근했던 것 같네요!

알려주신 블로그 읽어보았습니다. 관련해서 조금 더 검색하다보니 통합테스트/테스트 피라미드 관련 이슈이 해외에도 있었나 보더군요. 마틴 파울러가 아래와 같은 글을 썼더라구요! 읽으셨을 수도 있겠지만 한번 공유해봅니다.

https://martinfowler.com/articles/2021-test-shapes.html

블로그/유튜브 보면서 많이 배우고 있습니다. 감사합니다 :)

[jojoldu]

@sjquant 좋은 정보 감사합니다 :) 재밌게 잘 읽어보겠습니다!

[gon-sirloin]

개선된 코드가 굉장히 DDD에서 본 예제와 흡사하게 바뀌는군요! 어떤 방법론이든 좋은 코드의 결과물의 모양은 비슷한가봅니다:)

[jhkim593]

안녕하세요 해당 예시 같은 경우 만들어진 order 객체를 외부 저장소에 저장하는 구조인데 반대로 만약 외부 api에서 받아온 데이터를 로직에서 사용해야 하는 경우는 지금처럼 외부 의존성을 떼어놓을수가 없을 것 같은데 맞을까요?