안녕하세요 아렉스입 니 다 :< 어느덧 크리스마스 이브네요 :<
테스트를 작성하는 것에대한 이해가 깊어지길 바라는 마음으로 작성합니다.
테스트코드에 대한 방향성에 대해 고민한 두 집단이 있습니다.
London School 그리고 Detroit School
이 두 스타일은 각각 다른 환경과 필요에서 발전했으며, 테스트 작성 방식에도 뚜렷한 차이를 보입니다.
각 집단의 스타일을 이해하는 것은 테스트 초점을 통해 상황에 맞는 테스트 전략 수립이 가능하는데 도움을 줍니다.
Detroit School (Classicist)
유래
1990년대 후반 미국 디트로이트에서 Kent Beck과 그의 동료들이 Chrysler에서 C3 프로젝트를 진행하며 발전시킨 방식입니다. Test-Driven Development By Example 책에서 철학을 확인할 수 있습니다. 또한 Gerard Meszaros 가 출판한 xUnit Test Patterns 은 Detroit School 의 원칙을 기반으로 작성되었습니다.
특징
실제 객체를 사용하며, 객체의 최종 상태(State)와 동작(Behavior) 을 중심 검증합니다.
- 테스트는 "객체가 올바른 결과를 반환하는가?"에 초점을 둡니다.
- Outside-In 개발 방식 선호
장점
- 실제 시스템 동작을 더 잘 반영합니다. Classicist 접근법은 실제 의존성 객체를 사용하기 때문에 테스트 시나리오가 실제 시스템 동작을 더 잘 반영할 수 있습니다.
단점
- 실제 객체를 사용하기 때문에 실행 속도가 느릴 수 있음
- 외부 의존성 처리 필요함
London School (Mockist)
유래
영국 런던의 Extreme Programming (XP) 커뮤니티에서 시작되었습니다.
특히 Growing Object-Oriented Software, Guided by Tests (GOOS) 책의 저자인 Steve Freeman과 Nat Pryce가 주도했으며, 런던의 ThoughtWorks에서 일하면서 이 스타일을 발전시켰습니다.
특징
Mock 객체 를 적극적으로 사용 하여, 행위(Behavior) 중심 검증에 중점을 둡니다.
- 테스트는 "객체가 외부와 올바르게 협력하는가?"를 검증하는 데 초점을 맞춥니다.
- Outside-In 개발 방식 선호
장점
- 단위 테스트가 더욱 격리됩니다. 모의 객체를 사용시 의존성에 대한 것들을 테스트하지 않는다는 것을 의미합니다.
- 테스트 실행 속도가 향상됩니다. 모의 객체 사용시 실제 객체를 대신하기 때문에 테스트 실행 속도가 향상될 수 있습니다.
- 객체 간 결합도 파악에 용이합니다.
단점
- 과도한 Mocking으로 복잡도 증가
- 실제 동작을 잘 반영하지 못할 수 있다.
- Classist와 달리 내부적으로 장애가 발생해도 단순히 버그가 발생한 클래스에 대해서만 테스트 실패를 하게 된다.
결론
재미있는 점은 이 이름들이 공식적으로 정해진 것이 아니라, Martin Fowler가 2009년 그의 블로그 포스트 "Mocks Aren't Stubs"에서 이 두 학파를 구분하기 위해 사용한 이름이 업계 표준이 되었다는 것입니다.
두 도시는 각각 다른 산업 문화와 소프트웨어 개발 커뮤니티를 대표하며, 서로 다른 테스트 철학을 발전시켰습니다.
두 철학 모두 장단점이 있으며, 어떤 방법을 사용할지는 상황에 따라 달라집니다.
저는 기능에 대한 객체간 행위 검증은 Mocking을 통해 테스트하였고, 결제와 같이 도메인, 비즈니스 로직의 영역에서는 결제/환불에 대한 실제 객체를 테스트를 진행하였습니다.
위와 같은 경험으로 어떤 경우에 적합한지에 대해서 정리했습니다.
- 테스트 코드 작성 및 유지 관리의 용이성이 중요한 경우
-> Classicist - 실제 시스템 동작을 정확하게 반영해야 하는 경우
-> Classicist - 시험 대상 코드가 복잡한 의존성을 가지고 있는 경우
-> Mockist - 테스트 실행 속도가 중요한 경우
-> Mockist - 의존성 객체와 시험 대상 코드가 밀접하게 결합되어 있는 경우
-> Mockist
이와 같이 두 집단의 철학은 상호베타적이지않고, 상황에 맞게 적절히 사용하는 것이 좋다고 생각합니다.
하나의 관점을 가지는 것보다 다양한 관점을 접하면서 테스트라는 가치에 대해서 사유해보는 것을 추천드립니다. 너무 재밌었습니다 :>
현재 여러분들은 어떤 스타일로 테스트를 진행하고있나요 ?
참고
