Interaction Tests, Mocks & Refactoring in Embedded Software

1. Introduction to using Expect.

2. Introduction to Ceedling.

3. How to test main().

Homework 1-1

A deep dive into the concept of mocking.

We build up a small manually-mocked project (see `DIY` folder in course source code). This is for those who like to learn how things work as well as those who don’t quite grok how their compiler and linker make the magic happen.

We prepare to work on our second feature by refining our architecture some. This is a peek at how design happens — more on this later — and covers a simple case of mocking again.

Drive LEDs in some way that lets us check all digital inputs.

Homework 1-2

An optional unit with links to in-depth discussions of how CMock’s generated mocks operate.

Let's fix our blinking light. We want it to be a regular blink rate.

Homework 2-1

We introduce the Model-Conductor-Hardware pattern, using it to test drive our Analog subsystem. We also play with our module script to destroy the Analog files after we create a triad of MCH files!

We get the opportunity to reuse our Filter from the previous course. We discuss why this form of reuse isn’t all that rare but how we prepared ourselves for this style of reuse. We add in our filter code.

Iteration 2-2

Now that we have seen some good examples of TDD with interaction tests, we can revisit the question of why we are using mocks in the first place.

Our filter works-ish… except that a proper filter relies on a particular corner frequency. This means processing at a particular rate. So we test-drive our code development to write the actual timer code now.

Iteration 2-3

We check on how we did during the last two iterations, and we plan out what we’re going to accomplish in the next iteration.

It’s time to start talking to our device. Instead of implementing complicated messages like our results commands, we’re going to start with the simplest messages we can find.

We’ll be implementing the Version command first. We test drive the command handler using MCH again, though we call it Handlers-Conductor-Hardware for clarity. We also introduce _ReturnThruPtr and _ExpectAnyArgs for validating CommandHardware_CheckForMsg().

Iteration 3-1

We reuse the parser and the buffer from our first course.

Iteration 3-2

We learn another useful pattern, one particularly well suited for reuse.

Homework 3-3

We roll out our second command handler. This one actually requires our parser to pass in data!

We add our third command handler, this time enabling us to fetch results. We see how refactoring goes well with testing.

This is a lecture to review all that we've talked about so far.

Homework 3-4

How did this iteration go? What's on the agenda for next iteration?

We determine what we’re working on for the fourth iteration. We decide to focus on triggering first, then some related configurability with the parameter system. We end with a really short story about giving LED feedback.

From here on out we focus on the main flow of development.

We refactor our Capture system in preparation for capturing on a trigger.

Homework 4-1

We present concepts on how to design code and tests to minimize future work in the face of inevitable change and maintenance.

We build our first trigger and talk about testing static variables.

Homework 4-2

We start adding Trigger Modes and use this to introduce how custom Unity handlers make for much more awesome CMock failure messages.

Homework 4-3

We begin building our parameter system and configure our tests to process integers as hex codes instead of numerals.

Unity and CMocks’s :treat_as: support helps maintain CMock’s cross platform ability as well as provides you useful shortcuts for displaying your own custom C types.

We add the Param Set command and introduce the Observer pattern to help us build it.

Homework 4-4

We visit our finished feature list, admire our final test suite size, and we show a video walkthrough of a manual system test. Dr Surly is happy!

There’s always more to learn. Here are resources on how to continue your learning.