[컨버런스 리뷰] TDD는 오브젝트 디자인(객체 설계)에 도움이 되는가?

TDD는 테스트 작성 방법이 아니다.

오브젝트 디자인을 위한 도구다.

하지만 Red Green Refactor의 반복이 반드시 좋은 설계를 만들어낼까?

classical TDD(디트로이트 학파 TDD)는 in , out에만 집중한다.

테스트를 통해 탄생하는 설계는 창발적이다.

객체에 적절한 역할과 책임을 부여하고 객체 사이에 올바른 협력 관계를 만들어지는건 우연일 뿐이다.

(물론 그렇지 않다. 설계의 지향점은 분명히 존재한다!)

『객체지향의 사실과 오해』는 객체지향이란 무엇인가라는 원론적면서도 다소 위험한 질문에 답하기 위해 쓰여진 책이다. 안타깝게도 많은 사람들이 객체지향의 본질을 오해하고 있다. 가장

www.yes24.com

해당 세션의 연사는 London style(mockiest) 스타일의 TDD를 추상화의 도구로 활용한다.

먼저 DDD와 헥사고날 아키텍처 등의 큰 그림을 그린다.

그 다음 시스템의 바깥에서부터 내부로 점차 구현해나간다.

이때 시스템 내부의 바운더리 역할을 하는 것이 바로 mock이다

예를들어 컨트롤러는 아래와 같이 작업한다.

즉, 컨트롤러는 서비스 객체와 협력하게 된다.

따라서 서비스 객체는 추상화(mocking)의 대상이다.

validator, calculator나 때때로 책임이 명확하지 않은 객체가 필요할 때가 있다.

이 때는 classical TDD의 사이클로 전환해 창발적 설계를 시도한다.

이 창발적 설계에서 적절한 추상화를 끌어낼 수 있으면 mock으로 객체를 전환하거나, 책임이 명확하면 바로 mock 객체를 활용한다.

(in, out 만으로 검증할 수 있다는 것은 해당 객체가 순수한 연산만을 포함한다는 것이다. + 도메인 서비스는 순수해야 한다.)

정리하자면,

1. 머릿속에 아키텍처, 설계가 명확한 상태에서

2. 시스템의 밖에서 안쪽으로 추상화를 구체화하며 TDD를 시도한다.

3. 이때 시스템의 내부는 mock 객체로 추상화한다.

4. 초기 설계에서 누락되거나, 책임을 적절하게 할당할 수 없을것 같은 객체가 필요하다면, classical로 돌아가 해당 객체와의 협력을 만든다. 해당 객체의 역할과 책임이 적절하게 추상화되면, 그때부터는 해당 객체의 행동을 mocking 할 수 있다.

5. 객체 지향 설계 실력이 올라갈수록 TDD가 쉬워진다.

Development & Investing