My scribbling

TDD(Test Driven Development)에 대한 지식을 접할때마다 궁금하던게 있다.

TDD는 너무나 많은 시간을 테스트에 할애하도록 만드는 것이 아닌가?

우선 TDD는 테스트 케이스를 만들고 고객 요구사항 변경에 따라 변경된 기능에 따라서 테스트 케이스를 변경시켜야 하는 작업에 많은 시간을 소비한다.

또한, TDD를 할 때 처음에 계획된 테스팅 케이스들을 만들고 테스트하는 시간을 제외하더라도,
특정 개발자가 커다란 테스트 케이스를 돌릴때 테스트 툴이 보여준 failure 에 대해, 다른 팀과 연관이 되어 있거나, 솔루션의 라이브러리를 참조하여 조치 하기때문에 많은 비용과 시간을 쏟아야 할 수도 있다.

그러면 어떤 식으로 우리는 TDD를 접근하면 좋을까?

Wikipedia 에서는 소프트웨어 테스트를 다음과 같이 말하고 있다.

" Software testing is the process of checking software, to verify that it satisfies its requirements and to detect errors "

Software testing 에는 여러 기법들이 있지만, 우리는 테스트를 일반적으로 

1. 고객의 요구사항을 만족시키는지 확인하는 행위
2. 결함을 찾아내는 행위

라고 이해한다.

우리가 알고 있는 TDD 의 테스트는 정말 테스트처럼 보인다. 자동화된 Test Tool 을 사용하고, Test Case 를 만들고, Test 를 위한 여러가지 개발자들의 테크닉이 들어간다.

하지만 일반적인 테스트는 아니다. 테스트는 기능이 에러없이 잘 돌아가는지 수행하는 활동이다.

게다가 개발자들이 만드는 테스트 케이스는 Developer & Function Friendly 하다.
Adhoc Test(개발자 직관에 따르는 테스트기업)과는 비교할 수 없겠지만, 어쨌든 개발자들이 자신이 생각한 기능에 대한 테스트 케이스를 집어 넣기 때문에, 다양한 형태의 테스트가 어렵다.

그럼 TDD는 어떤 기능을 하고 있을까? 그리고 무엇을 기대 할 수 있나?

난 TDD의 테스트는 Test를 위한 것이 아닌, 소스코드에 있는 각종 Function의 Spec 을 결정해 주는 것이라 생각한다.
전통적인 Spec 을 명시하는 방법에서 벗어나, Function의 최소 Boundary를 결정해 주는것이다.

굳이 산출물로 이야기 하자면,
프로그램 사양서나 유즈 케이스 정의서 보다 작성하는 코드에 적합한 분석과 설계 경계를 지어주는 것이 아닐까?

항상 일정에 쫓기는 운명을 타고난 우리나라 개발자들에게, 이것을 소프트웨어의 품질을 견고하게 보다 향상 시킬 수 있는 기능 Spec 정의를 위한 단계라고 하면 어떨까? 대체할 수 있는 산출물을 줄이고 말이다.