TDD와 친해지기

[ TDD와 개발 ]

 

TDD는 Test Driven Development로 테스트 주도 개발을 뜻한다.

처음 느낀점은 순차적으로 개발한다기 보다 큰 윤곽과 기능을 먼저 구현한 후

테스트를 통해서 점진적으로 개발하는 것이라는 생각이 들었다. 

 

추상적인 개념에서 TDD의 핵심 개념은 결정과 피드백 사이의 갭에 대한 인식,

그리고 결정과 피드백 사이의 갭을 조절하기 위한 테크닉에 있다. 

 

 

 

TDD는 근본적으로 Agile 방법론이라는 라는 개념에서 출발한다.

Agile 방법론은 계획의 과다와 부족 사이에서 탄생한 개념이다.

계획이 없는 경우에 앞으로의 일을 예측하기 힘들고 효율적이지 못하다는 점에서 취약점을

계획이 너무 의존하는 경우 형식적인 절차를 따르는데 시간과 비용을 과다 투자하게 된다.

 

 

 

[ 개발론적 관점에서의 TDD ]

 

근본적으로 TDD가 개발에만 적용되지 않는 부분이라는 것을 알게되었다.

TDD는 모든 직무에서 적용할 수 있는 개념이다.

 

하지만 이를 개발론적 관점에 한정해 적용해 보자.

보통의 개발이라면 코딩을 마치고 테스트를 하는 느낌이 강하다.

하지만 TDD는 이와는 반대로 테스트를 먼저 작성하고 그걸 통과하는 코드를 만드는 과정을

반복하면서 피드백을 적극적으로 수용한다. 예를 들면,

 

1. 목표 코드를 작성한다. "아 이런식으로 코드를 구성해야겠다" 라고 결정

2. 피드백을 받는다. "이런식으로 코드를 만들면 이런저런 문제점이 생긴다." 라는식의 피드백을 수용.

3. 이 둘사이의 갭을 인식한다.

 

 

 

TDD는 '협력' 에 있어 가장 중요한 도구이다.

테스트를 반복적으로 통과하면서 프로젝트가 잘 진행되어가고 있는가 확인할 수 있다.

 

 

 

[ TDD의 Test의 의미 ]

 

'test' 란 단어는 보통 동사로 사용되지만

TDD 에 있어서 test는 명사로 사용된다. 명사로써의 test는 

테스트를 한다는 행위에서 벗어나 record로 남을 수 있다는 점에 있어서 중요하다.

test가 대상으로서 이용되는 순간 이것은 공유하기가 쉬워진다. 

이런 방식으로 코드를 공유하기 쉬워지게 된다.

 

 

 

TDD를 사용함으로써

내가 짠 코드를 빨리 설명할 수 있게 된다.

남이 짠 코드를 빨리 이해할 수 된다.

 

 

 

[ TDD의 절차 ]

 

TDD의 절차는 세가지로 설명 할 수 있다.

- 실패: 실패할 가능성이 있는 테스트 케이스를 먼저 만든다.

- 성공: 실패하는 테스트 케이스를 통과시키기 위해 코드를 작성해 테스트를 통과시킨다

- 리팩토링: 중복되는 코드나 개선할 수 있는 코드를 수정한다. 

리팩토링이 끝나면 그것을 반복한다

 

 

 

실패 -> 성공 -> 리팩토링

-> 실패 -> 성공 -> 리팩토링 

-> 반복...

 

 

 

[ 느낀점 ]

 

실패할 수 있는 코드를 먼저 작성하는 test 과정이 TDD의 핵심이다.

이는 버그에 낭비하는 시간도 최소한으로 할 수 있고 우리가 구현한 기능이 요구사항을

충족하는지 확인할 수 있다. 

 

이는 피드백과 협업의 시너지가 가장 중요한

개발업계에서 효과적으로 사용할 수 있는 개념이다.