TDD, 도대체 뭐길래?

 

 

 

설계 - 개발(코드작성) - 테스트(코드작성)
잘못되면 다시 설계수정..

 

 

 

요즘 아주 핫한 TDD가 무엇인지 궁금하기도 하고, 왜 이렇게 많은 사람들이 열광하게 되었는지 알아보기 위해 포스팅하게 되었다.

 

TDD(Test Driven Development)란

Test Driven Development의 약자로 '테스트 주도 개발'이라고 한다. 반복 테스트를 이용한 소프트웨어 개발 방법론으로 작은 단위의 테스트케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현함으로써 불필요한 설계를 피하고, 정확한 요구사항에 집중하도록 하는 방법론이다.

 

 

설계 -> 테스트(코드작성) -> 개발(코드작성)

 

만약, 설계가 잘못되었으면 테스트단계에서 바로 수정할 수 있기 때문에 효율적인 측면에서는 TDD가 좋다. (하지만, 모든 방법론에는 장점만 있는 것이 아니기 때문에 현재 상황에 TDD를 도입하는 것이 좋을지는 충분한 고민을 해봐야한다.)

 

TDD 개발 사이클

• 테스트케이스 실패 -> 수정
• 테스트케이스 성공 -> 리팩토링

 

왜 사용할까?

• 변화에 대한 두려움을 줄여준다. = 리팩토링이 편하다.
• 디버깅 시간을 줄여준다.
• 동작하는 문서 역할을 한다.

 

TDD 장점

1) 테스트 커버리지가 높아진다.

높다고 좋은 건 아니지만... 누군가는 나중에 작성해도 되는데 뭐가 다르냐?

>> 잊어먹거나 뒤로 미루다 결국 안할걸? 하기싫은 거 미리하자

 

2) 오버엔지니어링 방지

미래의 필요할 것 같은 코드를 미리 작성하지 않도록 정말 딱 필요한 기능만 만들 수 있게 해준다.

 

3) 설계에 대한 피드백이 빠르다

잘못 설계 했다면, 설계를 수정하면 된다. 복잡하고 잘못된 설계는 테케를 작성하기 힘들 것임. 설계를 바꿔라.

 

TDD의 오해

높은 응집을 유도하지 않는다

단일 책임 원칙과 인터페이스 분리 원칙 위배에 어떤 신호도 주지 않는다

인터페이스 일관성을 도출하지 않는다

리팩토링 단계는 좋은 구조를 안내하거나 좋은 구조를 갖도록 강제하지 않는다

 

설계 방법론이 아니다!!! 설계에 영향을 미치지 않는 건 아니지만

강한 결합과 의존성 원칙 위배를 경고하고 불명확한 설계지점을 알려준다. 단, 의지하면 안된다. 테스트하기만 좋은 안 좋은 설계를 하게 됨.

 

실패하는 이유

1. 코드가 이루고자 하는 가치나 기능을 테스트하기보다 그 기능을 어떻게 구현하고 있는지를 테스트한다.
2. 테스트케이스들이 구현체와 결합도가 높아진다.
3. 구현체를 리팩토링하면 결합되어있는 테스트 케이스들이 깨진다.

인터페이스 구현체가 아닌 인터페이스 자체를 테스트해야한다. 즉, 구현체를 리팩토링하더라도 테스트케이스가 깨지지 않도록 하는 것이 포인트이다.

 

 

테스트의 범위

• 통합 테스트: 여러 작업 단위가 연계된 워크 플로우를 테스트하기 위한 수단 (객체간, 서비스 간, 시스템 간)
• 기능 테스트 : 공개된 API의 가장 바깥쪽에 해당하는 코드 검사 (컨트롤러 호출, http 등)
• 부하 테스트 : 주어진 단위 시간동안 어플리케이션이 얼마나 만은 요청을 처리할 수 있는지 검사
• 인수 테스트 : 고객 또는 대리인이 정의되어진 모든 목적에 부합되는지 호가인해보고자 하는 검사

 

프로그램의 안정성을 높이려면 결국, 문제점을 빨리 발견하는 게 중요한 일이다. 변경을 자주하고 품질을 향상시키는 것이 핵심이다.

코드의 문서화 >> 샘플코드

 

좋은 단위 테스트: F.I.R.S.T 법칙

fast  빠르게

independent 독립적으로

repeatable 반복가능하게

self-validating 자가 검증하는

timely적시에