회사에서 해야하는 프로젝트에 TDD를 적용해 보겠다고 생각을 했었다.

보통 TDD의 단계는 다음과 같다.

1. 실패하는 테스트를 작성한다.
2. 실패하는 테스트를 간단하게 성공하게 만든다.
3. 다시 실패하는 테스트를 작성한다.(1번 보다 더 테스트를 할 수 있는...)
4. 다시 실패하는 테스트를 성공하게 만든다.

위의 단계를 기본적인 함수군을 테스트 하는데는 유효했다.

그런데 잘 캡슐화된(? 정말일까?) 클래스를 테스트 하면서 부터, 인터페이스를 public 으로 고치든지

새로운 클래스로 상속받아 임시로 protected: 를 public 으로 수정한 함수를 제공한다든지의 방법을

사용하게되었는데 -_-;

 이러면서 테스트가 조금씩 문제가 발생하기 시작했다. -_-

 그리고 뒤의 테스트를 추가하기 위해서 인터페이스가 바뀌면 이전의 테스트를 수정해야 하는 문제도

발생했다.

 그리고 결정적으로, 어떤 식으로 클래스의 동작을 제대로 체크할 것인가가 문제가 되었다.

내가 작성하는 프로그램은, 네트웍, GUI를 모두 사용하는 데, 이에 대해서 Mock을 사용할 것인지 아니면

실제로 테스트를 붙일것인지도 문제가 되었다.

 단순 UI와의 통신이 아니라, 나의 클래스는 UI 생성을 내부적으로 해야하는 기능도 있었기 때문에, 제대로

UI가 나타났는지도 테스트를 해야만 했다. -_-

 결국 일정이 급해지고, 이것 저것 수정하면 TDD는 잠시 무너진 T.T 그러나 단순 함수들에서도 실수가 많았는데 TDD를 이용하면서 단순 함수군에 대해서는 꽤 좋은 효과를 볼 수 있었다.

 이번 실패의 큰 원인은,

1. 테스트를 어떻게 할 것인지, 제대로 생각하지 못했다.

   1. 이게 제일 크다.

2.  네트웍, GUI 등에 대해서 테스트를 할 수 있는 인터페이스를 제대로 뽑지 못했다.

   1. 즉, 기존 설계가 좀 잘못되었다. -_-

 이번 경험을 삼아서 좀 더 제대로 설계를 하고, 제대로 TDD를 전개해 봐야겠다.

 TDD 프레임웍은 구글 테스트를 이용했다. 환경은 Window Mobile 6.1