So this is going to be a rapid introduction to T.D.D. for embedded systems.

Why?⌗

So what are the reasons we should use test driven development for an embedded system?

Pros:

  1. You will end up writing small throwaway programs to test stuff anyway.
  2. Encourages more modular code.
  3. Allows development of the software even without hardware.
  4. Reduces amount of needed debugging on the actual hardware.
  5. Tests document what the actual behavior of the code is.
  6. It makes refactoring the code base easy.

Without further ado onto the main concepts!

Definitions⌗

First lets look over some of the terms and buzzwords we need to know. This will make your life a lot easier when researching topics and looking for resources.

TDD :Test driven development, writing tests for code units this can be functions, classes etc.

Unit :A module or unit of code we want to test the behavior of.

Unity :A unit testing framework

CppUTest :Another unit testing framework/harness.

Test :Function that uses some style of assert statement to test the behavior or a unit of code.

Fake :Code that emulates some functionality to abstract hardware or software components

The loop/cycle⌗

The loop or development cycle for TDD is rapid. The main idea is too keep things moving and not get stuck trying to debug an issue for hours or days at a time later.

Another analogous loop would be the OODA loop; observe, orient, decide, act. It’s gives us precise steps to work in so that we can focus on building code.

  1. Write tests.
  2. Check they can fail.
  3. write code to make the tests pass Repeat

Why the tests matter⌗

The tests in our development cycle define the behavior of a unit. The behavior of code is what we really want to know most the time. The actual implementation isn’t what we want to test.

Codes documentation through tests allows another developer to pickup work on the project and test if their changes break anything.

TLDR; It lets you know your code does how you think it does.

Build Systems⌗

  • Make
  • Rake
  • CMake

I personally find Make and CMake to be better in terms of documentation.

To be continued!