post/implementing-tdd-in-practical-applications/

[giscus[bot]]

post/implementing-tdd-in-practical-applications/

TDD가 무엇인지 모르는 사람은 없습니다. 그런데 왜 하는 사람은 얼마 없을까요?

https://tech.kakaopay.com/post/implementing-tdd-in-practical-applications/

[heli-os]

안녕하세요 cdragon!

고전파로서 모킹을 최대한 사용하지 않으신다면, interface 기반으로 Fake Implementation을 만들고 spy를 주로 사용하시는걸까요? JPA를 사용할 떄 JPARepository에 대한 부분은 어떻게 처리하시는지도 궁금합니다 :)

[cdragon-cd]

헬리 안녕하세요~ 오랜만입니다.
말씀주신 부분에 제 생각을 말씀드리면, 스프링 기반 애플리케이션에서 service 부분은 통합테스트의 영역이라고 생각합니다.
도메인 로직을 처리하는 객체들은 본문의 예제처럼 작은 객체들로 분리하여 단위테스트가 이루어지고요.
이러면 JpaRepository 를 어떻게 처리할 것인가에 대한 고민이 많이 사라지는 것 같아요.

[heli-os]

@cdragon-cd 오오 감사합니다 ㅎㅎ 저도 비슷한 생각입니다! 나중에 기회되면 인사드리러 가겠습니다. 🫡🫡

[soeu2000]

pm관점에서 tdd를 수행하는 개발자를 많이 만나보기 쉽지 않았는데, tdd에 대한 개념과 실전에서 어떻게 쓰일 수 있는지 코드 예시를 통해 쉽게 이해할 수 있는 글인 것 같습니다.

[minsoozz]

좋은 글 감사합니다 😀

[Lay4U]

Given/When/Then (GWT) 패턴이 최근에 더 유명해진 것 같다고 하셨는데, 테스트 코드를 3A(Arrange, Act, Assert)로 작성하신 이유가 궁금합니다.

[cdragon-cd]

안녕하세요 이번에 글을 작성하게 된 계기가 켄트벡의 테스트주도개발이라는 책을 보고 난 이후라서요. 사내발표와 블로그에선 최대한 해당 책 내용을 기반으로 전달하고자 했습니다.

[renechoi]

좋은 글 작성해주셔서 고맙습니다. 'mock을 적극적으로 활용하는 게 좋을까?' 섹션을 읽으며 좋은 단위테스트가 가져야 할 리팩토링 내성 부분에서 멈칫, 했어요.

저 같은 경우 데이터 계층에서는 슬라이싱 테스트나 통합테스트로 테스트를 하고, 나머지에 대해서는 단위 테스트를 하면서 적극적으로 mocking을 하는 편인데요. 최근에는 gpt 도움으로 mock 데이터 생성도 자동화하고 있었는데 글을 읽으면서 좋은 테스트에 대한 고민이 깊어지게 되었네요.

혹시 '런던파' 쪽으로도 추천해주실 만한 책이 있다면 부탁드리겠습니다. 감사합니다 :)

[cdragon-cd]

안녕하세요. 본문에도 적은 것처럼 mock 라이브러리를 적극적으로 쓸수록 추상화보다는 구현과 가까워지는 것 같습니다. 런던파쪽 자료를 말씀주셨는데 죄송하지만 제가 접한 자료 중에 mock 을 적극적으로 이용하는건 당장 떠오르지가 않네요^^;

[ch200203]

최근에 TDD를 접하고 공부하고있는데 실무에서는 어떻게 사용하까 고민하고 있던 부분을, 가려운 부분을 긁어주셔서 너무 감사합니다.
너무 잘 읽고 갑니다~!

[psh5487]

좋은 분의 좋은 글 너무 잘 보았습니다!✏️

[zrohyun]

// findBy(userId)에서 findBy(userId, BetweenPeriod)로 내부 리파지토리 메서드가 변경됐을 뿐이지만 목킹 테스트코드는 깨짐

여기에서 그러면 mocking을 하지 않고 어떻게 하면 괜찮은 테스트방법이라고 할 수 있을까요..?

[cdragon-cd]

안녕하세요. 우선 해당 예제에서 테스트하고자 하는 대상은 service 객체의 recentBankAccounts 메서드입니다.
repository 에서 어떤 findBy 를 호출할 것이냐는 내부 구현에 해당하기 때문에 recentBankAccounts 메서드가 어떤식으로 구현되든 스펙이 변하지 않았다면 테스트는 통과해야 본문에서 언급한 리팩터링 내성을 갖게 됩니다.
그럼 어떻게 해야 리팩터링 내성을 갖게되는지 고민이 필요한데요. 특정 메서드의 행위를 조작하는 mock 라이브러리를 사용하기보다는, 실제 repository 처럼 repository 의 불변식을 충족하는 간단한 구현체를 전달하는게 가장 쉬운 접근법입니다. mock 라이브러리는 라이브러리의 종류나 설정에 따라 mocking 메서드를 호출하지 않으면 그 자체로 예외를 일으켜 테스트를 실패하게 만들기도 하는데, 순수하게 구현된 repository 객체는 그렇게 동작하지도 않고 내부에서 어떤 findBy 가 호출되는지를 중요하게 여기지도 않기 때문이죠.

그렇게 구현된 repository 를 전달해서 테스트코드를 실행하면 내부에서 findBy(userId), findBy(userId, BetweenPeriod) 둘 중 어느것을 호출하든 테스트 대상인 recentBankAccounts 의 반환값이 변하지 않는다면 테스트의 리팩터링 내성은 올라갑니다. 다만 이렇게 직접 repository를 구현하려고 하다보면 구현해야하는 메서드가 너무 많다던가 하는 현실적 문제에 부딪히게 되는데요. 이 부분에 대한 해법들도 있지만 저는 일단 이 전에 라이브러리나 프레임워크에 의존하지 않는 객체들을 분리하고, 이에 대한 단위테스트를 먼저 작성해보는걸 권장합니다. 본문에서 예로 작성한 BankAccountRemittanceHistoryCollection 같은 객체를 분리하는 방향으로요.

이런 문제들과 함께 testability와 좀 더 좋은 설계에 대한 고민을 해보시면 도움이 될거라 생각합니다.

[gayeong-kim0]

좋은 글 잘 읽었습니다!
요즘 AI로도 테스트 코드를 많이 사용하던데 AI를 활용해서도 사내에서 사용중인 것이 있으신가요?