출판사 서평
엄격한 한계와 물리적 제약 조건, 마이크로초, 킬로바이트 같은 진짜 ‘엔지니어’의 세계에 살고 있는 임베디드 개발자들은 TDD가 자바(Java)나 루비(Ruby) 같은 객체 지향 언어를 사용하고, 자원이 풍?족한 분야에서나 적용할 수 있는 방법이라고 생각한다.
애자일 전문가인 제임스 그레닝은 임베디드 소프트웨어 개발에 테스트 주도 개발을 적용해야 하는 이유와 적용하기 위한 방법을 간결하게 보여준다. TDD를 소개하는 다른 책들과 달리 특별히 펌웨어를 개발하는 개발자를 대상으로, 온전한 C 예제로 만든 상세한 코드로 설명을 전개하...
엄격한 한계와 물리적 제약 조건, 마이크로초, 킬로바이트 같은 진짜 ‘엔지니어’의 세계에 살고 있는 임베디드 개발자들은 TDD가 자바(Java)나 루비(Ruby) 같은 객체 지향 언어를 사용하고, 자원이 풍족한 분야에서나 적용할 수 있는 방법이라고 생각한다.
애자일 전문가인 제임스 그레닝은 임베디드 소프트웨어 개발에 테스트 주도 개발을 적용해야 하는 이유와 적용하기 위한 방법을 간결하게 보여준다. TDD를 소개하는 다른 책들과 달리 특별히 펌웨어를 개발하는 개발자를 대상으로, 온전한 C 예제로 만든 상세한 코드로 설명을 전개하고 있다.
또한 이 책은 TDD를 얘기하기는 하지만 그보다 훨씬 더 많은 얘기를 한다. 즉, 이 책은 C로 고품질의 임베디드 소프트웨어를 빠르고 안정적으로 개발하기 위한, 훨씬 더 완벽하고 수준 높은 프로페셔널한 방법을 알려 준다.
[ 추천사 ]
순수 임베디드 배경을 가진 나는 TDD에 대해 회의적이었다. 하지만 이 책을 옆에 끼고 난 다음에는 TDD에 뛰어들 자신이 생겼다. 심지어 디바이스 드라이버나 저수준 코드에 대해서도 TDD를 적용할 수 있을 것 같다.
- 마이클 바(Michael Barr), 『Programming Embedded Systems』와 『Embedded C Coding Standard』의 저자
사실 이 책의 제목은 잘못되었다. ‘C 임베디드 시스템 공예(Crafting Embedded Systems in C)’라고 붙였어야 한다. 이 책에서 TDD를 많이 이야기하기는 하지만 그것보다 훨씬 더 많은 것을 이야기하기 때문이다.
나는 이 책이 임베디드 소프트웨어 공학의 바이블이 될 것이라고 생각한다. 코드를 많이 읽을 준비를 하라. 이 책은 코드로 가득 찼다. 그리고 그 코드는 가르칠 내용이 많은 장인이 작성한 것이다. 그 코드 대부분이 C로 작성되었으며, 임베디드 시스템의 제약 많은 개발 환경이나 실행 환경에 100% 적용 가능하다. 여러분이 이 책과 그 속의 코드를 읽는 동안 제임스는 여러분에게 테스트, 설계 원칙, 리팩터링, 코드 냄새, 레거시 코드 관리, 디자인 패턴, 테스트 패턴, 그리고 그 이상을 가르쳐 줄 것이다.
- 로버트 마틴(Robert C. Martin), 『Clean Code』 저자
『임베디드 C를 위한 TDD』는 의심의 여지없이 이 주제에 관한 최고의 책이다. 코드 중심으로 진행되는 평이한 스타일 덕분에 이 책은 상냥하고 읽기 쉬운 책이다. 이 책은 TDD의 본질부터 시작하여 TDD를 충분히 숙달할 수 있도록 상세한 예제를 보여준다. 온전히 C를 다루고 있고, 또 이 분야의 다른 책들과는 달리 특별히 펌웨어를 개발하는 우리를 대상으로 쓰였기 때문에 이 장르에 있어서도 환영할 만하다.
- 잭 갠슬(Jack Ganssle)

순수 임베디드 배경을 가진 나는 TDD에 대해 회의적이었다. 하지만 이 책을 옆에 끼고 난 다음에는 TDD에 뛰어들 자신이 생겼다. 심지어 디바이스 드라이버나 저수준 코드에 대해서도 TDD를 적용할 수 있을 것 같다.
- 마이클 바(Michael Barr), 『Programming Embedded Systems』와 『Embedded C Coding Standard』의 저자

사실 이 책의 제목은 잘못되었다. ‘C 임베디드 시스템 공예(Crafting Embedded Systems in C)’라고 붙였어야 한다. 이 책에서 TDD를 많이 이야기하기는 하지만 그것보다 훨씬 더 많은 것을 이야기하기 때문이다.
나는 이 책이 임베디드 소프트웨어 공학의 바이블이 될 것이라고 생각한다. 코드를 많이 읽을 준비를 하라. 이 책은 코드로 가득 찼다. 그리고 그 코드는 가르칠 내용이 많은 장인이 작성한 것이다. 그 코드 대부분이 C로 작성되었으며, 임베디드 시스템의 제약 많은 개발 환경이나 실행 환경에 100% 적용 가능하다. 여러분이 이 책과 그 속의 코드를 읽는 동안 제임스는 여러분에게 테스트, 설계 원칙, 리팩터링, 코드 냄새, 레거시 코드 관리, 디자인 패턴, 테스트 패턴, 그리고 그 이상을 가르쳐 줄 것이다.
- 로버트 마틴(Robert C. Martin), 『Clean Code』 저자

『임베디드 C를 위한 TDD』는 의심의 여지없이 이 주제에 관한 최고의 책이다. 코드 중심으로 진행되는 평이한 스타일 덕분에 이 책은 상냥하고 읽기 쉬운 책이다. 이 책은 TDD의 본질부터 시작하여 TDD를 충분히 숙달할 수 있도록 상세한 예제를 보여준다. 온전히 C를 다루고 있고, 또 이 분야의 다른 책들과는 달리 특별히 펌웨어를 개발하는 우리를 대상으로 쓰였기 때문에 이 장르에 있어서도 환영할 만하다.
- 잭 갠슬(Jack Ganssle)

 

목차
1장 테스트 주도 개발
1.1 왜 TDD가 필요한가?
1.2 테스트 주도 개발이란 무엇인가?
1.3 TDD 물리학
1.4 TDD 마이크로 사이클
1.5 TDD의 이득
1.6 임베디드 환경에서의 이득
1부 시작하기
2장 테스트 주도 개발의 도구와 관례들
2.1 단위 테스트 하니스란?
2.2 Unity - C로만 작성된 테스트 하니스
2.3 CppUTest: C++ 단위 테스트 하니스
2.4 단위 테스트는 크래시를 일으킬 수 있다
2.5 네 단계 테스트 패턴
2.6 지금까지 우리는
3장 C 모듈 시작하기
3.1 테스트 가능한 C 모듈의 구성 요소
3.2 LED 드라이버가 하는 일
3.3 테스트 목록 작성하기
3.4 첫 테스트 작성
3.5 먼저 인터페이스를 테스트 주도로 개발하기
3.6 점진적 진행
3.7 테스트 주도 개발의 상태 기계
3.8 테스트 FIRST
3.9 지금까지 우리는
배운 것 적용하기
4장 완료까지 테스트하기
4.1 단순하게 시작해서 솔루션 키워가기
4.2 코드를 깔끔하게 유지하기 - 자주 리팩터링하기
4.3 완료될 때까지 반복하기
4.4 완료 선언 전에 한 걸음 물러서기
4.5 지금까지 우리는
배운 것 적용하기
5장 임베디드 TDD 전략
5.1 타깃 하드웨어 병목
5.2 듀얼 타기팅의 장점
5.3 듀얼 타기팅의 위험 요소들
5.4 임베디드 TDD 사이클
5.5 듀얼 타깃 비호환성
5.6 하드웨어로 테스트하기
5.7 빨리 가기 위해 속도 늦추기
5.8 지금까지 우리는
6장 좋아, 하지만……
6.1 우린 시간이 없어요
6.2 코드 작성 후에 테스트를 작성하면 왜 안 되나?
6.3 테스트를 유지 보수해야 할 것이다
6.4 단위 테스트가 모든 버그를 찾아낼 수는 없다
6.5 빌드가 오래 걸린다
6.6 우리에겐 기존 코드가 있다
6.7 메모리 용량이 제한되어 있다
6.8 우리는 HW와 상호작용해야 한다
6.9 C를 테스트하는데 왜 C++ 테스트 하니스가 필요한가?
6.10 지금까지 우리는
2부 협력자를 가진 모듈 테스트하기
7장 테스트 대역 도입하기
7.1 협력자
7.2 의존성 끊기
7.3 테스트 대역을 언제 사용하나?
7.4 C로 페이크 만들기, 그 다음은?
7.5 지금까지 우리는
8장 제품 코드에 스파이 심기
8.1 LightScheduler 테스트 목록
8.2 하드웨어와 운영체제 의존성
8.3 링크타임 치환
8.4 테스트 대상 코드에 스파이 심기
8.5 시계 제어하기
8.6 없는 경우 처리한 다음, 하나 있는 경우 처리
8.7 여러 항목 처리하기
8.8 지금까지 우리는
9장 런타임 연결 테스트 대역
9.1 무작위성 테스트
9.2 함수 포인터로 속이기
9.3 외과수술로 삽입된 스파이
9.4 스파이로 출력 검증하기
9.5 지금까지 우리는
10장 목(Mock) 객체
10.1 플래시 드라이버
10.2 MockIO
10.3 TDD로 드라이버 구현하기
10.4 디바이스 시간 초과를 시뮬레이션하기
10.5 이럴만한 가치가 있을까?
10.6 CppUMock으로 목 객체 만들기
10.7 목 객체 생성하기
10.8 지금까지 우리는
3부 설계와 지속적인 개선
11장 견고하고(SOLID), 유연하며,테스트 가능한 설계
11.1 SOLID 설계 원칙
11.2 SOLID C 설계 모델
11.3 요구사항의 변경과 문제 설계
11.4 동적 인터페이스로 설계 개선
11.5 타입별 동적 인터페이스로 유연성 향상시키기
11.6 설계는 얼마나 해야 충분한가?
11.7 지금까지 우리는
12장 리팩터링
12.1 소프트웨어의 두 가지 가치
12.2 세 가지 핵심 기술
12.3 코드 냄새와 이를 개선하는 법
12.4 코드 변형하기
12.5 성능과 크기 문제
12.6 지금까지 우리는
13장 레거시 코드에 테스트 추가하기
13.1 레거시 코드 변경 정책
13.2 보이스카우트 원칙
13.3 레거시 코드 변경 알고리즘
13.4 테스트 포인트
13.5 2단계 구조체 초기화
13.6 부딪혀가며 통과하기
13.7 특징 묘사 테스트
13.8 써드파티 코드에 대한 학습 테스트
13.9 테스트 주도로 버그 수정하기
13.10 전략적 테스트 추가
13.11 지금까지 우리는
14장 테스트 패턴과 안티패턴
14.1 장황한 테스트 안티패턴
14.2 복사-붙이기-변경-반복 안티패턴
14.3 도드라진 테스트 케이스 안티패턴
14.4 테스트 그룹 사이의 중복 안티패턴
14.5 테스트 무시 안티패턴
14.6 행위 주도 개발 테스트 패턴
14.7 지금까지 우리는
마무리하면서
4부 부록
A1 개발 시스템의 테스트 환경
A1.1 개발 시스템 툴 체인
A1.2 전체 테스트 빌드를 위한 메이크파일
A1.3 더 작은 테스트 빌드
A2 Unity 레퍼런스
A2.1 Unity 테스트 파일
A2.2 Unity 테스트 main
A2.3 Unity 테스트 조건 검사
A2.4 명령줄 옵션
A2.5 타깃에서 Unity 실행하기
A3 CppUTest 레퍼런스
A3.1 CppUTest 테스트 파일
A3.2 테스트 main
A3.3 테스트 조건 검사
A3.4 테스트 실행 순서
A3.5 기본 뼈대 파일을 생성해주는 스크립트
A3.6 타깃에서 CppUTest 실행하기
A3.7 CppUTest 테스트를 Unity로 변환하기
A4 시작하기 단계를 마친 LedDriver
A4.1 Unity로 작성된 초기 LedDriver 테스트
A4.2 CppUTest로 작성된 초기 LedDriver 테스트
A4.3 LedDriver 초기 인터페이스
A4.4 LedDriver 뼈대 구현
A5 OS 분리 계층 예제
A5.1 대체 가능한 동작을 보장하는 테스트 케이스
A5.2 POSIX 구현
A5.3 Micrium RTOS 구현
A5.4 Win32 구현
A5.5 분리 계층이 애플리케이션의 짐을 가져가기
참고문헌
찾아보기