Put the Knowledge to Work -- Test-Driven Development for Embedded C (for Shrinivasan Mani) by James W. Grenning -- Free eBooks online Reading

ibooksonline

Test-Driven Development for Embedded C
Table of Contents
1: Foreword by Jack Ganssle
2: Foreword by Robert C. Martin
3: Acknowledgments
4: Preface
- Who Is This Book For?
- How to Read This Book
- The Code in This Book
- Online Resources
5: Test-Driven Development
- Why Do We Need TDD?
- What Is Test-Driven Development?
- Physics of TDD
- The TDD Microcycle
- TDD Benefits
- Benefits for Embedded
Part 1 Getting Started
6: Test-Driving Tools and Conventions
- What Is a Unit Test Harness?
- Unity: A C-Only Test Harness
- CppUTest: A C++ Unit Test Harness
- Unit Tests Can Crash
- The Four-Phase Test Pattern
- Where Are We?
- Put the Knowledge to Work
7: Starting a C Module
- Elements of a Testable C Module
- What Does an LED Driver Do?
- Write a Test List
- Writing the First Test
- Test-Drive the Interface Before the Internals
- Incremental Progress
- Test-Driven Developer State Machine
- Tests Are FIRST
- Where Are We?
- Put the Knowledge to Work
8: Testing Your Way to Done
- Grow the Solution from Simple Beginnings
- Keep the Code Clean —Refactor as You Go
- Repeat Until Done
- Take a Step Back Before Claiming Done
- Where Are We?
- Put the Knowledge to Work
9: Embedded TDD Strategy
- The Target Hardware Bottleneck
- Benefits of Dual-Targeting
- Risks of Dual-Target Testing
- The Embedded TDD Cycle
- Dual-Target Incompatibilities
- Testing with Hardware
- Slow Down to Go Fast
- Where Are We?
- Put the Knowledge to Work
10: Yeah, but...
- We Don ’t Have Time
- Why Not Write Tests After the Code?
- We ’ll Have to Maintain the Tests
- Unit Tests Don ’t Find All the Bugs
- We Have a Long Build Time
- We Have Existing Code
- We Have Constrained Memory
- We Have to Interact with Hardware
- Why a C++ Test Harness for Testing C?
- Where Are We?
- Put the Knowledge to Work
Part 2 Testing Modules with Collaborators
11: Introducing Test Doubles
- Collaborators
- Breaking Dependencies
- When to Use a Test Double
- Faking It in C, What ’s Next
- Where Are We?
- Put the Knowledge to Work
12: Spying on the Production Code
- Light Scheduler Test List
- Dependencies on Hardware and OS
- Link-Time Substitution
- Spying on the Code Under Test
- Controlling the Clock
- Make It Work for None, Then One
- Make It Work for Many
- Where Are We?
- Put the Knowledge to Work
13: Runtime-Bound Test Doubles
- Testing Randomness
- Faking with a Function Pointer
- Surgically Inserted Spy
- Verifying Output with a Spy
- Where Are We?
- Put the Knowledge to Work
14: The Mock Object
- Flash Driver
- MockIO
- Test-Driving the Driver
- Simulating a Device Timeout
- Is It Worth It?
- Mocking with CppUMock
- Generating Mocks
- Where Are We?
- Put the Knowledge to Work
Part 3 Design and Continuous Improvement
15: SOLID, Flexible, and Testable Designs
- SOLID Design Principles
- SOLID C Design Models
- Evolving Requirements and a Problem Design
- Improving the Design with Dynamic Interface
- More Flexibility with Per-Type Dynamic Interface
- How Much Design Is Enough?
- Where Are We?
- Put the Knowledge to Work
16: Refactoring
- Two Values of Software
- Three Critical Skills
- Code Smells and How to Improve Them
- Transforming the Code
- But What About Performance and Size?
- Where Are We?
- Put the Knowledge to Work
17: Adding Tests to Legacy Code
- Legacy Code Change Policy
- Boy Scout Principle
- Legacy Change Algorithm
- Test Points
- Two-Stage struct Initialization
- Crash to Pass
- Characterization Tests
- Learning Tests for Third-Party Code
- Test-Driven Bug Fixes
- Add Strategic Tests
- Where Are We?
- Put the Knowledge to Work
18: Test Patterns and Antipatterns
- Ramble-on Test Antipattern
- Copy-Paste-Tweak-Repeat Antipattern
- Sore Thumb Test Cases Antipattern
- Duplication Between Test Groups Antipattern
- Test Disrespect Antipattern
- Behavior-Driven Development Test Pattern
- Where Are We?
- Put the Knowledge to Work
19: Closing Thoughts
Part 4 Appendixes
20: Development System Test Environment
- Development System Tool Chain
- Full Test Build makefile
- Smaller Test Builds
21: Unity Quick Reference
- Unity Test File
- Unity Test main
- Unity TEST Condition Checks
- Command-Line Options
- Unity in Your Target
22: CppUTest Quick Reference
- The CppUTest Test File
- Test Main
- TEST Condition Checks
- Test Execution Order
- Scripts to Create Starter Files
- CppUTest in Your Target
- Convert CppUTest Tests to Unity
23: LedDriver After Getting Started
- LedDriver First Few Tests in Unity
- LedDriver First Few Tests in CppUTest
- LedDriver Early Interface
- LedDriver Skeletal Implementation
24: Example OS Isolation Layer
- Test Cases to Assure Substitutable Behavior
- POSIX Implementation
- Micrium RTOS Implementation
- Win32 Implementation
- Burden the Layer, Not the Application
25: Bibliography

Put the Knowledge to Work

Start your own LedDriver so that you can follow along in the next chapter. You will find starter files in code/SandBox. Look there for a README.txt file.
Write a test list for a first-in first-out CircularBuffer that holds a series of ints.
Start test-driving the CircularBuffer. Choose tests that check the initial state and explore its interface. Only choose tests that can pass with hard-coded return results. You will need to modify the makefile so it can find the CircularBuffer files. You will get a chance to finish it after the next chapter.

Footnotes

[6]	The Edsger Dijkstra quote is from The Humble Programmer[THP] .
[7]	`stdint.h` is only guaranteed to exist in compilers that are C99 or later.
[8]	Found at http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
[9]	See http://www.c2.com/cgi/wiki?DoTheSimplestThingThatCouldPossiblyWork.

Copyright © 2011, The Pragmatic Bookshelf.

godaddy analytics