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