우아한테크코스 4기 백엔드이신 더즈님과 티키님이 Classic TDD와 Mockist TDD이라는 주제로 발표를 해주셨다. 이 발표에서는 TDD를 하면서 어떤 테스트 방식을 선택해야 할지 고민해본 적이 있는 개발자들에게 두 가지 방식의 차이를 소개하고, 상황에 따라 적절하게 활용할 수 있는 방법을 제시하셨다.
테스트 더블의 개념
발표에서는 먼저 테스트 더블에 대한 개념을 짚고 넘어가셨다. 테스트 더블이란 실제 객체 대신에 가짜 객체를 사용해 테스트를 진행하는 것으로, Mock 객체가 그 예시 중 하나다. Mock 객체는 호출될 메서드와 그 결과를 미리 정의해두고, 해당 메서드가 실제로 호출되었는지를 확인하는 방식이다.
Classic TDD와 Mockist TDD의 차이
Classic TDD와 Mockist TDD는 테스트 더블의 사용 여부에 따라 차이를 보인다.
- Classic TDD는 실제 객체를 사용하여 테스트를 진행하며, 주로 상태 검증을 통해 객체 내부의 상태를 확인하는 방식이다.
- Mockist TDD는 Mock 객체를 사용해 행위 검증을 통해 메서드 호출 여부를 확인한다.
상태 검증 vs 행위 검증
- Classic TDD는 상태 검증을 통해 메서드가 실행된 후 객체의 상태가 예상대로 변했는지 확인한다. 이 방식은 테스트가 더 안정적이며, 구현이 바뀌더라도 테스트가 깨지지 않는다.
- Mockist TDD는 행위 검증을 통해 메서드가 호출되었는지 확인한다. 이 방식은 구현 변경에 민감하며, 테스트가 자주 깨질 수 있지만, 객체 간의 상호작용을 명확히 알 수 있는 장점이 있다.
Inside-Out vs Outside-In 개발 방식
Classic TDD와 Mockist TDD는 개발 접근 방식에서도 차이를 보인다.
- Classic TDD는 Inside-Out 방식으로, 도메인에서 시작해 레드-그린-리팩토링을 반복하며 점진적으로 개발을 진행한다.
- Mockist TDD는 Outside-In 방식으로, 상위 계층부터 하위 도메인까지 내려가며 테스트를 진행한다.
Inside-Out의 특징
- 장점: 빠른 피드백, 오버 엔지니어링 방지, 시스템 전반적인 이해 없이도 시작 가능.
- 단점: 객체 간의 협력이 어색할 수 있고, 잘못된 public API 설계 가능성.
Outside-In의 특징
- 장점: 객체 간의 상호작용을 명확히 정의하고, 객체지향적인 설계를 촉진할 수 있음.
- 단점: 설계에 대한 깊은 이해가 필요하고, 오버 엔지니어링으로 이어질 가능성이 있음.
결론
두 가지 방식 모두 각각의 장단점이 있으며, 상황에 따라 적절하게 선택하는 것이 중요하다고 강조하셨다. Classic TDD와 Mockist TDD 중 어느 하나만을 고집할 필요는 없으며, 각 방법을 상황에 맞게 유연하게 사용해야 한다고 조언하셨다. 이러한 방식으로 더 나은 테스트와 개발 경험을 쌓을 수 있을 것 같다.
Get your hands dirty