[[TableOfContents]]
== TDD ==
 === TDD를 하면서 언제 생각을 많이 해야하는지? ===
 테스트를 만들 때인가? 테스트에 맞게 동작을 수행하는 코드를 작성할 때인가? --[Leonardong]
  사람마다 다를것 같긴 하지만, 나의 경우는 테스트를 작성하기 전 TODO List 를 작성할때 가장 고민을 하고 시간이 오래걸린 것 같다. 뭘 만들것인지에 대한 이해가 제대로 되지 않은 상태에서는 도대체 '뭘 해야 할지, 어떤 결과를 기대해야 할지'를 모르기 때문. :) 한편, 만일 TODO 리스트 작성시 시간이 너무 지체된다 싶으면 빨리 '어떤 결과를 기대해야 하나(Test 디자인)' 이란 질문을 하고 테스트를 작성해보는 방법을 추천. 저 질문이 앞에서의 '뭘 할까?'라는 질문의 모호함을 보완해주기 때문. 무엇을 해야 할지 감이 안올때는 가장 간단한 Input-Output 을 서술해봄으로서 조금씩 구체화시켜나갈 수 있음. '예제에 의한 구체화'란 방법은 참 유용함. --[1002]
 
 {{|
...전략...
테스트를 작성할때엔 '이미 완성되어있는 잘 된 API' 를 상상하며 작성한다. 잘 만들어진 API는 같은 일을 하더라도 직접 호출해줘야 하는 함수의 갯수가 적고 이해하기 편하며 '무엇'을 해주는지 그 메소드가 말해준다. 적게 코드를 써도 많은 일을 해주는것이다. 그리고, 테스트로서 컴퓨터의 컴파일러에게 코드작성을 위해 해야 할 일들을 묻고, 인터페이스를 만들고. 그리고 구현하고, 다시 구현된 코드를 Refactoring 한다. 
...후략... ''-[TestDrivenDevelopment]에서''
 |}}

=== 간단한 C++ 에서의 TDD 참고 함수 ===
{{{~cpp

int gNumTests = 0;
int gNumFailures = 0;
void Assert(bool condition)
{
	++gNumTests;
	if(!condition)
	{
		++gNumFailures;
	}
}
#define Assert(cond)	AssertImpl(cond, #cond, __LINE__, __FILE__)

void AssertImpl( bool condition, const char* condStr, int lineNum, const char* fileName)
{
	++gNumTests;
	if(!condition)
	{
		++gNumFailures;
		printf("file %s', line %d, assert '%s' failed\n", fileName, (int)lineNum, condStr);
	}
}
void printTestResult() {
		printf("%d tests run, %d tests failed\n", (int)gNumTests,(int)gNumFailures);
}
int main(int argc, char* argv[])
{
	Assert(1==2);
	printTestResult();
	return 0;
}
}}}
== 참고 자료 ==
 * [http://xper.org/wiki//xp/TestDrivenDevelopment?action=fullsearch&value=TestDrivenDevelopment&literal=1 XPER의 TDD 관련 자료들]
 * [http://wiki.tdd.or.kr/wiki.py tdd.or.kr]