TDD가 실패하는 이유 - by 이규원님

OkkyCon 세미나 영상을 보고 배운 키워드를 정리합니다.

먼저 팀이 아닌 개인이 실패하는 이유부터 살펴보자.

Science vs Engineering. 개발자는 후자에 가깝다. 제약된 자원으로 문제를 해결해야 한다. TDD가 문제해결에 도움이 된다면 도입한다. 그런데 그렇지 않으면 도입하지 않는다. 이렇게 실용적인 판단을 해야한다.

우리가 보호해야 하는 것

우린 도메인에 가장 많은 자원을 써야한다.

우리가 제어할 수 없는 것

따라서 우리는 우리가 보호해야할 것들을 우리가 제어할 수 없는 것들로부터 분리시킬 필요가 있다. 이를 위해 어떻게 설계를 해야할까?

설계

그런데 당신은 아마..

..구현을 테스트하고 있을 것이다.
구현 방식을 테스트하면 어떤 문제가 생길까? 구현의 내부요소들과 테스트 케이스가 결합 되어있다. 리팩터링이라도 한번 하면 만들어놓은 테스트 케이스들이 쓸모 없어질 수 있다. 그럼 코드를 바꿀 때마다 테스트 케이스를 바꿔야하므로 비용이 늘어난다.
어떻게 회피할까?
정보 숨김(Information Hiding) 을 생각해볼 필요가 있다.
On the Criteria To Be Used in Decomposing System into Modules
Information distribution aspets of design methodology - David Parnas, 1971
정보 숨김은 어려운설계 결정과 변경될 가능성이 높은 설계 결정을 다른 모듈로부터 숨기는 것이다.
빈번하게 바뀌는 것들에 테스트케이스를 의존시키지 말고, 바뀔 가능성이 적은 견고한 인터페이스에 의존시키자. 구현이 아니라 설계를 테스트하자.
..레거시와 함께 살고 이를 탓할 것이다.
원래 레거시를 벗어날 수 없다. 내가 지난 주에 작성한 코드도 레거시다. 레거시가 있는 상태에서 어떻게 TDD를 진행할 수 있을까? 깨끗함을 유지하는 코드를 감싸는 어댑터를 만들어서 레거시로부터 결합을 떨어뜨리자.

Fail-fast 전략을 위해 아래 프로세스를 가져간다.

문화도 굉장히 중요하다.두 가지 공유가 중요하다고 본다. 1) 목표 2) 지식

아키텍쳐도 굉장히 중요하다.

낮은 결합
높은 응집
도메인 모델 보호
도메인 모델과 플랫폼을 생각해보자. 자바 개발자들은 테스트 얘기를 하다가도 기승전 스프링 얘기를 하는데, 그 이유가 우리에게 가장 중요한 도메인 모델을 스프링(플랫폼)에 맡겨버리기 때문이다. 도메인 모델 곳곳에 스프링 코드가 퍼져있다. 그럼 어떻게 해야하는가? 도메인 모델과 플랫폼을 분리시켜서 독립적으로 존재하게 해야한다. 플랫폼은 말 그대로 도메인 모델을 호스팅하는 역할을 해야한다. 플랫폼이 도메인 모델을 깊숙히 파고들면 안된다. 그래야 도메인 모델을 테스트하기 용이하다.
이번 라이브 코딩에서 쓸 애플리케이션의 아키텍쳐다. 서비스에 카프카 쓰는건 좋은데 비즈니스 로직이랑 연결시키지만 말아라.
MVVM에서도 view는 테스트하기 어렵지만 얇게 만들 수 있다. model, view model을 테스트하자.

우선 목적을 분명히, 구체적으로 하자.

목적: 소프트웨어 사용자에게 어떤 가치를 전달할 것인가?
- 멋진 기능 만들어주세요 -- X
- 시각적인 데이터를 만들어서 명확하게 목적을 공유하자.
분석
작업 설계
- 소프트웨어 변경은 어떤 세부 작업들이 있는가?
- 각 작업들은 어떤 순서로 진행되어야 하는가?
- 각 작업들은 누가 담당하는가?

자 TDD를 해보자.

메세지를 확인하고 테스트가 잘 작성되었다는 확신을 가진 다음 그린단계로 넘어가야한다.

Q&A

단위 테스트를 넘어선 통합 테스트는 언제 만들어야할 것인가? 단위테스트 2000개쯤 있는데, 메뉴얼 테스트, 기능 테스트도 따로 한다. 외부 시스템 통합시키는 프로젝트의 경우에는 'fake 서비스'를 임시로 만들어서 제대로 통합이 되는지를 확인하기도 한다.

Last updated 3 years ago