멘토 Pick! 25년 3월 셋째 주 아티클 모음
F-Lab : 상위 1% 개발자들의 멘토링
안녕하세요 여러분!
이번 주도 카카오 출신 멘토님께서 이번 주에 직접 선정한 아티클을 공유드립니다!
멘토's Pick에서 트렌디한 인사이트를 놓치지 마세요! 🚀
🤔 들어가기 전에 알아두면 좋습니다!
- 대부분 아티클은 영문으로 제공됩니다. 영문 글을 읽을 때 크롬 번역 플러그인을 쓰면 읽기가 불편하나, 크롬 플러그인 하나를 설치하면 한국어를 읽듯이 좀 더 쉽게 영어 아티클을 읽을 수 있습니다. Trancy Chrome 플러그인을 설치 후 더 쉽게 읽을 수 있습니다.
- 아티클을 읽고 어떤 점을 더 고민해 보고, 생각해 보면 좋을지 제시해 주시는
멘토님의 Comment도 잘 활용해 보시면 좋습니다!
💡The Practical Test
- Mike Cohn이 제안한 테스트 피라미드를 기반으로 자동화된 테스트를 만들기 위한 방법론을 설명합니다.
- 단위테스트부터 UI 테스트까지 각 테스트를 피라미드 계층으로 구분하여 자동화된 테스트를 작성하는 방법에 대해 깊은 수준으로 논의합니다.
- 수동 테스트를 자동화된 테스트로 바꾸기 위한 방식을 이해할 수 있습니다.
💌 멘토님의 Comment
“이상적인 테스트 전략은 단위 테스트를 가장 많이 작성하고, 통합 테스트와 UI 테스트는 점점 줄여가는 구조입니다. 하지만 실무에서는 이 피라미드를 유지하기가 쉽지 않습니다.
특히 통합 테스트의 비중이 커지면서 단위 테스트보다 더 많이 작성되는 역피라미드(Anti-pattern)가 발생하는 경우가 많습니다. 역 피라미드가 발생하는 일반적인 이유로 단위 테스트가 실제 환경과 너무 동떨어져 있어 신뢰하기 어려우며, 데이터베이스, API, 캐시 등 외부 요소가 필수적인 서비스에서는 단위 테스트만으로 충분한 검증이 어렵습니다. UI 테스트는 유지보수가 어려워 줄이고 싶지만, 그렇다고 서비스 테스트가 많아지면 속도가 느려진다는 점이 있습니다.
그렇다면, 테스트 피라미드를 이상적인 형태로 유지하면서도, 실무에서 현실적으로 적용할 수 있는 최적의 전략은 무엇일까요?
단위 테스트의 범위를 어떻게 설정하는 것이 가장 효율적인지 고민해볼 필요가 있을 것 같습니다.”
💡테스트는 어떻게 좋은 코드를 만드는가(feat. 험블 객체 패턴)
- 테스트코드 작성시 Test double을 어떤식으로 생성하고 제어할 것인지에 대해 험블객체 패턴을 적용함으로 풀어낸 방법을 소개하고 있습니다.
💌 멘토님의 Comment
"비즈니스 로직에 데이터베이스와 캐시 레이어가 포함될 경우, 테스트 코드의 신뢰성을 확보하는 것이 쉽지 않다는 점에 공감합니다. 특히, 외부 자원을 사용하는 경우 멱등성을 유지하기 어렵고, 실행할 때마다 결과가 달라질 가능성이 크기 때문에 테스트가 안정적이지 않을 수도 있습니다.
이러한 문제를 해결하기 위해 다양한 접근법이 있지만, 각각의 방식이 가진 트레이드오프도 무시할 수 없는 요소인 것 같습니다. 단위 테스트의 비중을 높이고 Mock 객체를 활용하는 것이 현실적인 대안이지만, 이 경우 실제 환경과의 차이로 인해 운영 환경에서 발생할 수 있는 문제를 완전히 포착하지 못하는 한계가 있습니다.
Mocking, Dependency Injection, 컨트랙트 테스트 등 다양한 접근법이 있지만, 모든 조직이 이를 효과적으로 적용하는 것은 쉽지 않습니다. 결국 "테스트 코드의 비용을 감당할 수 있는가?"라는 현실적인 고민이 따라올 수밖에 없습니다.
실제로 테스트 전략을 세울 때 어떤 기준을 적용하는 것이 효과적이라고 생각하시나요?"
깊이 있는 인사이트와 현실적인 조언이 담긴 멘토님들의 인터뷰와 커리어 성장 콘텐츠가 데브클럽에서 정기적으로 업데이트되고 있습니다.
실력 있는 현직 개발자 멘토들과 직접 소통하고, 생생한 실무 노하우와 커리어 성장 전략을 배워보세요!
이 컨텐츠는 F-Lab의 고유 자산으로 상업적인 목적의 복사 및 배포를 금합니다.
