임베디드 C를 위한 TDD

엄격한 한계와 물리적 제약 조건, 마이크로초, 킬로바이트 같은 진짜 ‘엔지니어’의 세계에 살고 있는 임베디드 개발자들은 TDD가 자바(Java)나 루비(Ruby) 같은 객체 지향 언어를 사용하고, 자원이 풍족한 분야에서나 적용할 수 있는 방법이라고 생각한다. 애자일 전문가인 제임스 그레닝은 임베디드 소프트웨어 개발에 테스트 주도 개발을 적용해야 하는 이유와 적용하기 위한 방법을 간결하게 보여준다. TDD를 소개하는 다른 책들과 달리 특별히 펌웨어를 개발하는 개발자를 대상으로, 온전한 C 예제로 만든 상세한 코드로 설명을 전개하고 있다. 또한 이 책은 TDD를 얘기하기는 하지만 그보다 훨씬 더 많은 얘기를 한다. 즉, 이 책은 C로 고품질의 임베디드 소프트웨어를 빠르고 안정적으로 개발하기 위한, 훨씬 더 완벽하고 수준 높은 프로페셔널한 방법을 알려 준다.

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 분리 계층이 애플리케이션의 짐을 가져가기 참고문헌 찾아보기