임베디드 C를 위한 TDD

인상깊은 부분

많은 C개발자들이 플랫폼마다 달라지는 코드를 처리할때 조건부 컴파일을 이용한다. 나는 여러분에게 조건부 컴파일을 피하라고 제안한다. 코드를 지저분하게 만들기 때문이다. 또한 특정 상황에서 어떤 코드가 실제로 컴파일 되는지 알아보기도 힘들다.

(중략) 플랫폼마다 따로 구현될 함수들의 프로토타입을 정의하는 헤더 파일을 만들었다. 그런 다음 각 플랫폼 구현을 해당 디렉터리에 넣어서 분리시켰다. 우리는 전처리기 대신에 컴파일러와 링커를 사용했다.’

추천사

… 이 책 ‘임베디드 C를 위한 TDD'는 기존의'코딩 많이 하고 디버깅 시작하기’ 식의 개발 방법과 TDD가 어떻게 다른지 본질적인 차리를 잘 보여준다. 기존의 방식에서는 버그들이 오래 전에 작성한 코드로부터 발생한다. 그만큼 버그를 찾기도 어렵다. 반면에 TDD로 개발한다면 지금 발견한 버그가 바로 10분 전에 박성한 코드에서 나오게 된다. 마치 집시로의 속옷처럼 버그들이 노출된다. 테스트가 실패한다고? 그럼 버그는 분명 여러분이 마지막으로 작업한 곳에 있을 것이다

1쪽

디버깅은 처음 코드를 작성하는 것보다 두 배는 더 어렵다. 따라서 코드를 작성할 때 당신의 영리함을 100% 발휘했다면, 그 코드를 디버깅하기에는 당신의 영리함이 부족할 것이다. - 브라이언 케니핸(Brain W. Kernighan)

12쪽

코드를 수정하기 위해 테스트를 작성하려는데 쉽게 작성할 수 없다면 서례적 문제가 좃기에 드러난 것이다. TDD는 코드 부패 탐지기다.

재미와 보상 : TDD는 개발자들에게 즉각적인 만족감을 안겨준다.

임베디드 환경에서의 이득

개발 시스템 상에서 버그를 해결함으로써 타깃 텀파일, 링크, 업로드로 이어지는 시간이 오래 걸리는 작업의 횟수를 줄인다.

40쪽

TDD에서는 조금씩 자주 수정한다. 정말 자주 빌드하고 테스트한다.

43쪽

virtualLeds를 드라이버에 전달하는것은 ‘의존성 주입'을 사용한 것이다.

56쪽

C로 개발하면서 테스트 주도 개발을 하는 것은 도전적인 일이다. TDD는 독립적인 기능 단위에 가장 적절하다. 일반적인 C프로그래밍 방식에서는 독립적인 기능 단위로 개발하지 않는 경우가 많다. 모듈 경계가 명확하지 않고 언저적으로도 한계가 있다.

92쪽

긴 타깃 업로드 시간은 한 번의 빌드에 너무 많은 수정 내용을 포함시키게 만든다. 이렇게 되면 문제가 더 많이 생기고, 결국 디버깅이 많아지게 된다.