[OKKYCON: 2018] 이규원 - 당신들의 TDD가 실패하는 이유

1. 개요

• 성공하는 팀이 어떻게 하고 있는지 하나의 사례를 엿본다.
• 우리 프로젝트
  - Non-Startup
  - Business Service (B2B)
  - Global Market
  - Competitors (경쟁사들 존재)
  - Message-Driven (메시지 기반)
  - Multitenancy (멀티테넨시: 여러 사용자가 동시에 한 서비스를 공유하여 사용)
  - Scalable (범위성: 확장하거나 커져도 기존의 기능이 제대로 작동하는 능력)
  - Responsive (반응형)
• 우리 팀
  - 본인
  - 1년차 1명
  - 신입 2명
• 초급 개발자들이 위와 같은 요구사항에 어떻게 적응하였는지 얘기해보려 한다.

 

2. TDD가 실패하는 이유 (개인과 조직의 시각)

• 준비가 안됐기 때문
• 성급하게 도입하고 성급하게 결과를 보려고 한다.

 

2-1. 당신은 이렇게 하지 않는다. (개인의 실패)

• 과학과 엔지니어링의 차이
  - 과학은 진리를 탐구하는 것
  - 엔지니어링(프로그래밍)은 과학과 예산(개발 비용) 사이의 균형을 맞추는 것
• 왜 TDD를 작성하는 사람들은 모든 코드를 TDD로 작성하려 하는가?라는 질문
  - TDD를 많이 하지만 모든 것에 하지는 않는다.
  - 과학자가 아니라 엔지니어이기 때문에
  - TDD를 통해 프로덕트를 빠르고 안정적으로 만들 수 있다면 적용한다.
  - 그렇지 않은 것들에 대해서는 하지 않는다.
• TDD 뿐만 아니라 다른 테스트 기법도 많이 있다.
• 나 혹은 팀이 준비가 안되어 있으면 TDD를 사용하지 않는 것이 좋다.

우리가 보호(테스트 및 관리)해야 하는 것

• AWS
• 스프링 (위 둘은 알아서 잘함)
• 도메인 (비즈니스의 핵심)

어떻게하면 핵심인 도메인에 투자할 수 있을까?

• 우리가 제어할 수 없는 것(외부 세상)에는 투자하지 않는다.
  - 실 세계
  - 인프라 (운영체제, 클라우드 플랫폼 등)
  - 외부 서비스 (결제 서비스 등)
  - 레거시 (리팩토링이 되지 않은 과거에 작성된 코드들)
• 외부 세상과 분리할 수 있는 좋은 설계
  - 낮은 결합
  - 높은 응집
  - 도메인 모델 보호
• 설계를 테스트하라
  - 

TDD를 실패하는 사람이 하는 테스트

• (1) 코드가 이루고하자는 가치나 기능을 테스트하기보다 그 기능을 어떻게 구현하고 있는지를 테스트한다.
• (1) 결국 테스트 케이스들이 구현체와 결합도가 높아진다.
• (3) 구현체들을 리팩토링하면 결합되어있는 테스트 케이스들이 모두 깨져버림 -> 테스트에 대한 부담 증가

 

 

 

정보 숨김 (Information Hiding)

• 리팩토링 할 가능성이 큰 설계 결정(구현체)들을 다른 모듈(외부)로부터 숨기는 것

 

• 구현체가 아니라 설계 (인터페이스)를 테스트해야 한다.
• Interface와 Implementaion을 구별하는 것은 어려운 문제이기 때문에 결합과 응집에 대해 고민해야 함.

 

2-2. 당신의 팀은 이렇게 하지 않는다. (팀의 실패)

프로세스

• 점진
• 반복
• Fail-Fast
  (언젠가는 발생할 실패를 가능한 한 빨리 맛보고 이른 시점에 해결해야 함.)

반복 주기

• 계획 (설계)
• 실행 (구현)
• 평가 (테스트)
• 대부분은 설계와 구현은 하지 않고 구현만 한다.
• 테스트를 하지 않고 커밋을 한다.

문화

• TDD에 있어서 문화도 굉장히 중요한 역할을 한다.
• 공유
  
  - 목표
  우리는 어떤 결과물을 목표로 가고 있는지 팀 내에서 명확하게 공유되어야 한다.
  
  - 지식
  도메인 지식, 기술 지식의 공유