1. TDD생활백서
   
   우리 일상의 특정한 일을 TDD로 하면 어떤 모습일까? 실제 프로그래밍으로 들어가기전 TDD 개념을 이해하는데 도움이 된다.
   
2. 사칙연산
   
   사칙연산을 직접 TDD로 구현한다. 프로그래밍 기법보다는 실제 프로그래밍에서 적용하는 방법을 익힐 수 있다.
   
3. string관련 처리
   
   자주 사용하는 string 관련 처리를 TDD로 구현해 본다.
   
4. 작은 개발
   
   실제 개발하고 있는 일에 대해서 요구사항을 단순화하여 TDD로 구현해 본다.
   

1. 스펙에 대한 이해의 부족.
   
2. 전역변수의 사용이 많음.
   
3. 코드복잡도가 높음.(if문이 많음)
   
4. 함수의 이름으로 함수의 하는 일을 유추하기 어려움.
   
5. 함수의 사이즈가 크고 하나의 함수에서 여러가지 일을 수행하므로 분리가 되어있지 않음.
   

고객과 신뢰를 쌓기 전에는 리팩토링보다는 힘이 들더라도 기존 코드에 대한 Unit Test를 먼저 진행하는게 바람직(?) 하다고 생각한다.
언젠가 나의 시간과 노력이 보상 받을 때가 올것이라는 희망을 가지며...

꽤 복잡한 하나의 파일에 대해서 unit test를 작성한 후 '이건 정말 필요하겠다'라고 생각되는 것들을 정리해 보자.

1. Naming rule
   
   test group 및 test 함수에 대한 이름 정하는 방법
   
2. fake 함수 방법
   
   • fake 함수를 좀더 세련되게 사용하는 방법
     
   • fake 함수 파일명 정하기
     
3. setup 방법
   
   test group에 대해서 동일하게 setup, teardown 적용이 가능하다. 코드의 중복 및 코드의 깔끔함을 위해서 setup 및 teardown을 잘 활용하도록
   

1. verify 변수 선언
   
2. condition setting
   
3. test
   

원하는 동작 : 2개 수의 입력을 받아 합을 구하기
입력 : 2개의 입력으로 1, 3
결과 : 결과가 4가 나오는지 확인한다.

1. verify 변수 선언: result = 4, firstInput = 1, secondInput = 3
   
2. test : CHECK(result, Add(firstInput, secondInput))
   

if (param1 == 0)

return 10;

else if(param1 == 1)

return 11;

else if(param1 == 2)

return 22;

....

return expected_return_fake_A[];

void Func_A()
{

//전역변수에 값을 할당하거나 return값이 전혀 없는 경우
....
....
....
if(condition_A == 1)

fake_A(input1);

else

fake_A(input2);

이런 경우에 대해서
void fake_A(int param1)
{

fake_A_?ParameterSave = param1;

int Getfake_A_?ParameterSave()
{

return fake_A_?ParameterSave;

CHECK_EQUAL(expected_value, Getfake_A_?ParameterSave()); 로 체크함.

마치 전문가가 되기 위해서 주 40시간이 시간 투입 노력이 드는 것과 같은 원리가 아닐까?

• Outside-In
  
  high-level functional test -> low-level unit test
  state-based test
  
• Inside-Out
  
  high-level analysis & design -> technology-facing programmer supporting tests
  interaction-based test
  

Avatars of TDD

1. 첫 Test 작성
   
   글짓기를 할 때 가장 어려운 것이 처음 시작을 어떻게 할 것인가하는 것이다.
   TDD도 마찬가지로 첫 Test를 작성하는게 어렵다. 첫 Test 작성이 어려운 이유는 무엇을 Test해야 하며 또 어느 수준으로 해야하느냐는 것인다. 개발자들을 보면 simple한 것부터 시작하는 것에 어려움을 느낀다. 잡생각이 많이 든다. 따라서 simple한 Test 자체를 생각해 내는데 어려움을 느낀다. 생각이 많다. 따라서 무엇부터 시작할까에 대해서 초점을 맞추기도 쉽지 않아 보인다.
   
2. Interface -> Implementation
   
   첫 Test 작성 후 해당 Test를 만족시키는 코드를 작성하여 Test를 통과시켰다. 이렇게 2, 3번의 Test는 Interface에 해당한다. 이후 Test를 만족시키기 위해서 단순 Interface만으로는 Test를 통과시킬 없으며 이 단계에는 Implementation을 작성해야 한다. Interface에서 난이도에서 Implementation으로 전이되는 순간의 나이도의 차이가 크게 느껴진다. '그저 Test를 만족시켜라'라는 요구조건이 더이상 쉽게 느껴지지 않기 때문이다. 이 단계에는 실제 구현할 때와 드는 느낌이 다르지 않다.
   
3. 유지보수
   
   Test 코드도 유지 보수가 필요하다. Test의 개수가 늘어나야 느끼는 어려움이라 처음에는 가슴에 와닿지 않을 수 있다. 하지만 실행코드의 변경에 따른 유지보수 뿐만 아니라 시간이 지난 후에 새로운 테스트를 추가할 경우에 느끼는 어려움 중에 하나다.
   

• s/w 준비
  
  • Eclipse
    
  • MinGW
    
  • MSYS
    
  • CppUTest
    
• 설치
  
• Path설정
  
  • 윈도우 Path 환경변수에 추가 (MinGW\bin, MSYS\1.0\bin)
    
• CppUTest import
  
• CppUTest Build
  

• 기업적용동향
  
  • TDD를 적극적으로 활용하는 회사는 대부분 30인 이하 s/w 개발 회사
    
  • 외국 대기업의 경우도 TDD를 적용하는 회사가 거의 없음
    
    적용은 원하나 확산에 문제가 있다고 함.
    
  • 많은 사람들을 변화시키기에 역부족 TDD가 녹아들기에는 어려운 상황이라 판단됨
    
• TDD 수련시간
  
  • TDD 세션 발표자의 경우 2년의 경험이나 수련이면 TDD를 자연스럽게 사용할 수 있다고 함. => 아무리 좋은 경험이라도 시간으로 성숙시켜야 의미를 가질 수 있다.
    
  • 공유회에 참석한 분들에게 묻다. (현재 TDD를 적극활용하고 있는 사람은?)
    
    • 현재 TDD를 적용하고 있다고 한 참석자들의 경우 전원이 2년 이상 적용하여 진행 중이라고 한다. 2년 이하의 한 명도 없다. 이게 어찌된 일일까?
      
  • 항상 TDD로 사고하고 TDD를 적용해 보기
    
• 개발관리 Tool
  
  • Story로 관리하며 각 Story의 완료(done) 여부는 항상 자동화된 Test를 통해 확인하고 관리되어야 한다.
    
  • 결국 최근에 개발된 개발관리 Tool을 팀이나 조직에서 활용하여 효과를 보기 위해서는 반드시 TDD나 BDD, AT가 필요하다.
    
• 이전 TDD와 달라진 점은?
  
  • 우리가 이전까지 책으로 보고 배운 TDD와 비교해서 색다른 방법이나 색다른 도전의 변화는 느낄 수 없었다.
    
  • TDD의 Test실행 시간을 줄이려는 노력과 Test Code 유지보수에 대한 발표가 있었다.
    
  • TDD를 어떤 식으로 발표하거나 교육할 것이냐에 대한 세션이 있었다.
    
  • BDD 방식의 교육도 좋을 듯.
    

0131103628

그렇다면 나는 어떤 도움을 주면 될까?

1. TDD 환경설정해 주기
   
2. 몇 가지 예제를 통해 사용 방법 설명
   

Test Code는 읽기 쉬워야 한다.

Clean Code 124Page

1. 자기 공정의 테스트는 자기가 책임진다.
   
   s/w 개발의 경우 개발자보다는 테스트부서나 품질부서에서 실시하고 있음.
   
2. 자사뿐만 아니라 협력사까지 Just In Time
   
3. Push or Pull방식 실습 체험
   
   Pull방식이 효과적. 실습 후 결과를 통해 시간, 제고, cost 분석하여 나온 결론
   
4. 기계처럼 일하는데 행복한가?라는 질문에 대한 토요타 직원의 답변
   
   행복하다. 이전 방식에서는 화장실가기도 힘들었지만 지금은 가능하다. 정확히 어떻게 가능한지는 모르겠지만 현재 방식에 만족감을 표시했다고 했다.
   

• UI Layer:
  
  • 시나리오 기반 BDD 작성
    
• Middle Layer:
  
  • UI Layer의 시나리오 기반으로 Middle Layer의 API들이 정의 되었다는 가정.
    
  • Middle API 각각의 input에 대한 output을 Test 한다.
    
• System Layer:
  
  • Middle Layer의 API에 의해 System Layer의 API가 정의 되었다는 가정.
    
  • System API 각각의 input에 대한 output을 Test 한다.
    

1. 미들웨어
   
   System과 UI Layer 중간에 있는 미들웨어라서 사용되는 시나리오를 볼려면 UI에서 사용하는 것을 기준으로 시작해야 한다.
   
2. 함수들이 복잡하다.
   
   함수가 길고 많은 일을 해서 너무 복잡하더라.
   
3. 이해하기 어려운 상태의 코드
   
   함수가 복잡한거 이외에 DTV 스펙과 관련된 용어들이 변수명이나 함수명으로 사용되어 동작을 이해하기 위해서는 Domain Knowledge가 필요했다.
   
4. 개발자도 시나리오를 잘 모른다.
   
   개발자들은 지금까지 유지보수만 해왔다. 문제가 생기면 그때 문제점을 찾기 위해서 디버깅한다. 이는 코드가 복잡하기에 이해하는 작업을 포기한게 아닐까 싶다. 보기 쉽게 고치는 것도 어려운 상황.
   
5. 촉박한 시간
   
   100,000 line의 코드에 95%의 coverage 품질의 Test를 달아야 하기에 시나리오 하나하나를 따지면서 할 수 있는 상황이 아니였다.
   
6. 개발하는 사람 따로 Test Code작성하는 사람 따로
   
   개발자들이 Test Code 작성은 자기의 일이 아니라고 생각했다. 하기 싫은 일을 억지로 하는 느낌도 받았다. 결국 우리팀원이 거이 대부분의 일을 할 수 밖에 없었다.
   

1. 100,000 line 코드에 대해서 문제가 자주 발생하는 시나리오에 대해서 Test Code를 작성한다.
   
2. 문제가 자주 발생하는 시나리오에 대해서만
   
3. 복잡도가 높은 부분에 대해서만
   

1. 담당자와 간단한 인사
   
2. TDD 테스팅 4가지 방법
   
   1. 함수의 return값을 테스트
      
   2. state가 바뀌는 변수를 테스트
      
   3. fake함수의 변수를 테스트
      
   4. 1, 2, 3번 혼용
      
3. 개발자가 원하는 긴 함수에 대해서 리팩토링
   
4. 리팩토링한 함수에 대해서 Unit Test 달기
   

우연에 내 정면에 있는 남자분 발견. 이 분도 같은 TDD 책을 펼쳐놓고 공부하고 있다. 이분은 나이가 좀 들어 보이며 직장인으로 판단된다.

TDD의 열기가 이렇게 뜨거울 줄이야.
확산속도가 꽤 빠른거 같다.