Test Driven Development

In Agile software development software is developed iteratively, it changes, come to that in waterfall development software changes. Each time software changes there is the potential to break something, and tests are how we can find defects. Using test driven development ensures that all code is tested and bugs are detected very quickly driving down development costs and delivering faster.

Test coverage is just one of the benefits of TDD, designing code to pass tests impacts the design of the software, forcing decoupling and helping to create better designs.

TDD may have even more significant beneficial effects in Embedded Software Development than other branches of software engineering. TDD forces us to write software that is independent of hardware (increasing reusability). TDD is orders of magnitude faster to write and test than testing directly on the hardware (reducing time to market). TDD allows hardware to be mocked making it significantly easier to test hardware error conditions (increasing reliability). TDD allows time to be mocked allowing real time algorithms to be executed faster than real time (reducing time to market).

James Grenning Wingman Software

David is a seasoned embedded systems engineers with loads of experience. I met David first as a client and then later he joined the ranks of the independent consultant and trainer. He's helped me with clients and they could not have been happier. We've collaborated numerous times. His experience in TDD, XP, and design are extensive. His creativity, enthusiasm and experience would help any team looking to improve.

Ruben Sweden

Enthusiastic and clear delivery of the Test Driven Development course. David is passionate about TDD and is able to transfer that onto his students.

This training course helps you build knowledge, understanding and skill in the engineering practices needed to build great embedded C code. You learn how to build flexible and modular software with very few defects, software that can have a long useful life. We teach you how to prevent defects and how to keep code clean over years of evolving needs.

Among other things, you'll learn the difference between Debug-Later Programming (the most popular programming technique on the planet) and Test-Driven Development.

Learning Model

We learn new skills by doing, not just reading, listening, and thinking. Engineers are not so interested in changing how they work if the change does not help solve some identified problem. We’ve found this learning cycle to be invaluable to attendees of our courses.

Present a problem -- problems motivate change
Present a potential solution -- the idea that may help
Demonstrate part of the solution -- remove ambiguity
Participant does an exercise -- learn by doing
Experience debrief -- identify and discuss both positive and negative reactions

In this course, we repeat this learning cycle, growing skills with each iteration. Our goal is to build new skills on top of the attendees' existing skills.

Course Length Options

2 days - Hands-on classroom only. This course can be delivered live-via-the-web
4 days with Legacy Code Workshop (Recommended for existing code)
4 days with Walking Skeleton Workshop (Recommended for greenfield)
For smaller groups a one day workshop is available.

Audience

Embedded Software Developers
Software Developers
Technical team leaders
Managers that want to know more about the technology they manage

Course Outline

Module Objective: Software developers make mistakes. Mistakes undetected become defects with potentially huge costs. In this section, attendees can learn the motivations behind TDD and how the short test-driven cycles may help prevent defects.

Why Test Driven Development?
What is Test Driven Development?
The Microcycle
Exercise
Debrief

During the debrief, we explore what people liked about TDD and what concerns them. Most attendees like the experience, but also have a serious concerns or two. It is important to bring the concerns into the open. This is a rare opportunity to reflect on how we work and to envision how TDD may help us improve.

Adapting TDD to Embedded Software Development

Module Objective: Look at what is special about embedded systems programming, and some of the current industry-standard practice inefficiencies. We hope to show that TDD is well-suited for improving the embedded developer's product quality, as well as reducing some of the frustrations and waste when testing code in the target environment.

What is Special about Embedded Systems Development?
- No hardware until late in the development cycle
- Hardware with defects
- Long edit, build, test cycles
- Add your own unique problems here!
Running Tests the Development System
Risks of Development System Testing
Embedded TDD Cycle
The Role of Continuous Integration
Test Project Structure

TDD and Collaborating Modules - testing the code in the middle

Module Objective: The most valuable code you have (the code with the potential longest life) has dependencies. This code embodies what makes your product special. Automated tests help preserve your investment, allowing changes that have fewer unwanted side effects (defects!). We'll look at principles and techniques to guide developers in creating modular, testable, and tested embedded software. We'll introduce Spies and Fakes. You'll see how Spies and Fakes can fully exercise the code under test.

Object Oriented Principles Applied to embedded C/C++
Designing to interfaces
Information hiding
Substitutability
Spying on the Hardware
Faking the Time
Link-time Fake
Exercise
Debrief

Keeping Tests Clean

Module Objective: Tests have many valuable uses. One overlooked value of tests is that they are documentation. Tests provide an executable specification of the code under test. This document shows how the code is supposed to be used and how it is supposed to work. This document is unambiguous; it's code! This document warns you whenever the code differs from the specification. To get the most value from tests as documentation, tests must be written to be read and understood.

Tests as Detailed Documentation
Four-Phase Test Pattern
Given, When, Then
Arrange, Act Assert
Test Smells
Duplication in Tests

Test-Doubles

Module Objectives: There is more to test-stubs than the Spy and the Fake. We'll look at an overview of Test-Doubles and when to use them.

Taxonomy of Test-Doubles
Choosing Real or Test-Double

Test-Driving Next to the Silicon With Mock Objects

Module Objective: How close to the silicon can we get value from TDD? We can get to within a single C instruction of the hardware. In this module, we dig into The Mock Object. Mocks are great for faking the hardware while testing a device driver. Mocking has other uses as well and is quite powerful. It also hurts test readability so we'll look at when to use Mocks and when to use other kinds of Test-Doubles.

The Problem Solved by Mock Objects
TDD One Instruction Away from the Hardware
Specifying and Satisfying Expectations
Exercise
Debrief

Refactoring -- Overview

Module Objective: As requirements and users' needs change, code must change. Design is so important, we don't just do design once at the beginning of the development effort. Design is a continuous process. We accept that changing design is dangerous, and the tests created by the test-driven developer provide a safety-net to lock in code behavior as your product design evolves.

Refactoring (changing the structure of code, without changing its behavior) is a step in the TDD microcycle used when we need to clean up a mess. We'll also refactor code so that a new feature can be dropped in. This module provides and overview of the mindset and the critical skills needed to evolve designs for a long useful life.

Refactoring Defined
Critical to a Healthy Business
Critical Skills
Code Smells
Envisioning
Transforming
TDD's Positive Influence on Design

Working with Legacy Code -- Overview

Module Objective: Now we face the reality that we have code that was not created with TDD. We've seen how TDD can help guide creating tested, modular and loosely coupled software. The reality: our code has problems. We don't have time to stop all feature development and retrofit our code base with tests. We'll look at the pragmatic approach to incrementally improving your valuable code base.

Legacy Code Mindset
The Cost of Doing Business
Where and How to Add Test and Refactor
Boy Scout Rule -- leave the campsite better than you found it
Incremental Improvement
Legacy Change Algorithm
Crash to Pass Algorithm