TestDrivenDevelopment - Revision history

Maintenance script: Table transclusion repair v1

2026-03-27T12:46:19Z

Table transclusion repair v1

← Older revision		Revision as of 12:46, 27 March 2026
Line 5:		Line 5:
	사람마다 다를것 같긴 하지만, 나의 경우는 테스트를 작성하기 전 TODO List 를 작성할때 가장 고민을 하고 시간이 오래걸린 것 같다. 뭘 만들것인지에 대한 이해가 제대로 되지 않은 상태에서는 도대체 '뭘 해야 할지, 어떤 결과를 기대해야 할지'를 모르기 때문. :) 한편, 만일 TODO 리스트 작성시 시간이 너무 지체된다 싶으면 빨리 '어떤 결과를 기대해야 하나(Test 디자인)' 이란 질문을 하고 테스트를 작성해보는 방법을 추천. 저 질문이 앞에서의 '뭘 할까?'라는 질문의 모호함을 보완해주기 때문. 무엇을 해야 할지 감이 안올때는 가장 간단한 Input-Output 을 서술해봄으로서 조금씩 구체화시켜나갈 수 있음. '예제에 의한 구체화'란 방법은 참 유용함. --[1002]		사람마다 다를것 같긴 하지만, 나의 경우는 테스트를 작성하기 전 TODO List 를 작성할때 가장 고민을 하고 시간이 오래걸린 것 같다. 뭘 만들것인지에 대한 이해가 제대로 되지 않은 상태에서는 도대체 '뭘 해야 할지, 어떤 결과를 기대해야 할지'를 모르기 때문. :) 한편, 만일 TODO 리스트 작성시 시간이 너무 지체된다 싶으면 빨리 '어떤 결과를 기대해야 하나(Test 디자인)' 이란 질문을 하고 테스트를 작성해보는 방법을 추천. 저 질문이 앞에서의 '뭘 할까?'라는 질문의 모호함을 보완해주기 때문. 무엇을 해야 할지 감이 안올때는 가장 간단한 Input-Output 을 서술해봄으로서 조금씩 구체화시켜나갈 수 있음. '예제에 의한 구체화'란 방법은 참 유용함. --[1002]

	~~{{\|~~
	...전략...		...전략...
	테스트를 작성할때엔 '이미 완성되어있는 잘 된 API' 를 상상하며 작성한다. 잘 만들어진 API는 같은 일을 하더라도 직접 호출해줘야 하는 함수의 갯수가 적고 이해하기 편하며 '무엇'을 해주는지 그 메소드가 말해준다. 적게 코드를 써도 많은 일을 해주는것이다. 그리고, 테스트로서 컴퓨터의 컴파일러에게 코드작성을 위해 해야 할 일들을 묻고, 인터페이스를 만들고. 그리고 구현하고, 다시 구현된 코드를 Refactoring 한다.		테스트를 작성할때엔 '이미 완성되어있는 잘 된 API' 를 상상하며 작성한다. 잘 만들어진 API는 같은 일을 하더라도 직접 호출해줘야 하는 함수의 갯수가 적고 이해하기 편하며 '무엇'을 해주는지 그 메소드가 말해준다. 적게 코드를 써도 많은 일을 해주는것이다. 그리고, 테스트로서 컴퓨터의 컴파일러에게 코드작성을 위해 해야 할 일들을 묻고, 인터페이스를 만들고. 그리고 구현하고, 다시 구현된 코드를 Refactoring 한다.
	...후략... ''-[[TestDrivenDevelopment]]에서''		...후략... ''-[[TestDrivenDevelopment]]에서''
	~~\|}}~~

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

Maintenance script: Repair batch-0003 pages from live compare

2026-03-27T00:29:12Z

Repair batch-0003 pages from live compare

← Older revision		Revision as of 00:29, 27 March 2026
Line 37:		Line 37:
	printf("%d tests run, %d tests failed\n", (int)gNumTests,(int)gNumFailures);		printf("%d tests run, %d tests failed\n", (int)gNumTests,(int)gNumFailures);
	}		}
	int main(int argc, char* argv[])		int main(int argc, char* argv[])
	{		{
	Assert(1==2);		Assert(1==2);

imported>Unknown at 05:28, 7 February 2021

2021-02-07T05:28:12Z

New page

__TOC__
== TDD ==
=== TDD를 하면서 언제 생각을 많이 해야하는지? ===
테스트를 만들 때인가? 테스트에 맞게 동작을 수행하는 코드를 작성할 때인가? --[[Leonardong]]
사람마다 다를것 같긴 하지만, 나의 경우는 테스트를 작성하기 전 TODO List 를 작성할때 가장 고민을 하고 시간이 오래걸린 것 같다. 뭘 만들것인지에 대한 이해가 제대로 되지 않은 상태에서는 도대체 '뭘 해야 할지, 어떤 결과를 기대해야 할지'를 모르기 때문. :) 한편, 만일 TODO 리스트 작성시 시간이 너무 지체된다 싶으면 빨리 '어떤 결과를 기대해야 하나(Test 디자인)' 이란 질문을 하고 테스트를 작성해보는 방법을 추천. 저 질문이 앞에서의 '뭘 할까?'라는 질문의 모호함을 보완해주기 때문. 무엇을 해야 할지 감이 안올때는 가장 간단한 Input-Output 을 서술해봄으로서 조금씩 구체화시켜나갈 수 있음. '예제에 의한 구체화'란 방법은 참 유용함. --[1002]

{{|
...전략...
테스트를 작성할때엔 '이미 완성되어있는 잘 된 API' 를 상상하며 작성한다. 잘 만들어진 API는 같은 일을 하더라도 직접 호출해줘야 하는 함수의 갯수가 적고 이해하기 편하며 '무엇'을 해주는지 그 메소드가 말해준다. 적게 코드를 써도 많은 일을 해주는것이다. 그리고, 테스트로서 컴퓨터의 컴파일러에게 코드작성을 위해 해야 할 일들을 묻고, 인터페이스를 만들고. 그리고 구현하고, 다시 구현된 코드를 Refactoring 한다.
...후략... ''-[[TestDrivenDevelopment]]에서''
|}}

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

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]