이 상품은 구매 후 지원 기기에서 예스24 eBook앱 설치 후 바로 이용 가능한 상품입니다.
|
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 테스트 FIRST3.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 MockIO10.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 테스트 mainA2.3 Unity 테스트 조건 검사A2.4 명령줄 옵션A2.5 타깃에서 Unity 실행하기A3 CppUTest 레퍼런스A3.1 CppUTest 테스트 파일A3.2 테스트 mainA3.3 테스트 조건 검사A3.4 테스트 실행 순서A3.5 기본 뼈대 파일을 생성해주는 스크립트A3.6 타깃에서 CppUTest 실행하기A3.7 CppUTest 테스트를 Unity로 변환하기A4 시작하기 단계를 마친 LedDriverA4.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 분리 계층이 애플리케이션의 짐을 가져가기참고문헌찾아보기
|
|
엄격한 한계와 물리적 제약 조건, 마이크로초, 킬로바이트 같은 진짜 ‘엔지니어’의 세계에 살고 있는 임베디드 개발자들은 TDD가 자바(Java)나 루비(Ruby) 같은 객체 지향 언어를 사용하고, 자원이 풍족한 분야에서나 적용할 수 있는 방법이라고 생각한다. 애자일 전문가인 제임스 그레닝은 임베디드 소프트웨어 개발에 테스트 주도 개발을 적용해야 하는 이유와 적용하기 위한 방법을 간결하게 보여준다. TDD를 소개하는 다른 책들과 달리 특별히 펌웨어를 개발하는 개발자를 대상으로, 온전한 C 예제로 만든 상세한 코드로 설명을 전개하고 있다. 또한 이 책은 TDD를 얘기하기는 하지만 그보다 훨씬 더 많은 얘기를 한다. 즉, 이 책은 C로 고품질의 임베디드 소프트웨어를 빠르고 안정적으로 개발하기 위한, 훨씬 더 완벽하고 수준 높은 프로페셔널한 방법을 알려 준다.
|