This document discusses automated testing for embedded C software. It introduces Lars Thorup and provides an agenda for the document. It then defines automated testing, describes the Unity testing framework for embedded C, and provides an example of how to handle dependencies in testing. It advocates for continuous integration, breaking dependencies through abstraction and injection, and explains how automated testing can improve software quality through faster development and preventing bugs.

2. Who is Lars Thorup?
● Software developer
● Web: C# and JavaScript
● Embedded C++ for several
devices using agile and
automated testing
● Coach: Teaching agile and
automated testing
● Advisor: Assesses software
projects and companies
● Founder and CEO of
BestBrains and ZeaLake

3. Agenda
● What is automated testing?
● Unity, test framework for embedded C
● Code example
● Why should we write automated tests?
● Questions

4. What is automated testing?
● Developers write test ● Automated execution of all
programs test programs

5. The Unity testing framework
● Small memory footprint ● Many test functions
● ASSERT_TRUE
● Pure C ● FAIL
● ASSERT_EQUAL
● Optional tools to generate ● ASSERT_WITHIN
test runners automatically ● ASSERT_BITS
● ASSERT_NOT_NULL
● Alternatives in C++
● ASSERT_MEMORY
● CppUnit
● Google Test

6. How do we handle dependencies?
● The flow example
● a flow sensor
● generates pulse counts proportional to actual flow
● calculate average flow rate with regular intervals
● The dependencies in the flow example
● the sensor creating the pulse interrupt
● recurring timer event
● thread safe counting
● Decouple the dependencies
● Pulse: provide a callback to the FlowSensor component
● Timer and Counting: inject components into the Flow component
● flow.c

7. Dependencies, on device
main.c
Listen
GetRate
flowSensor.c flow.c
Pulse
GetTime
timerImpl.c
Increment
counterImpl.c

8. Dependencies, in test
flowTest.c
Pulse
GetRate
flow.c SetTime
GetTime
timerStub.c
Increment
counterImpl.c

9. Strategy for testing embedded software
● Continuous Integration
● Automate build and test execution
● On desktop, simulator and/or the device
● Break dependencies
● Hardware Abstraction Layer
● Simulate time measurements and timer events
● Standardize on frequently used stubs
● Use mock objects for testing protocols
● Dependency injection
● Link time, where possible
● Run time, using function pointers, where necessary

10. Why should we write unit tests?
● Speed up development
● Because of all the things we no longer have to waste time on
● Test Driven Development vs Debug Later Programming
● Avoid piling up technical dept (manual testing, bug fixing)
● Typing code is not where the bottleneck is
● Find bugs faster
● Trivial bugs found immediately
● QA can do exploratory testing earlier and more extensively
● Prevent bugs from reappearing
● Never fix a bug until we have a failing test
● Improve the software design
● Loose coupling is required to write tests

11. Links to further resources
● List of testing tools for C and C++
● http://www.opensourcetesting.org/unit_c.php
● Book
● http://pragprog.com/titles/jgade/test-driven-development-for-
embedded-c
● Experiement on the benefits of TDD
● http://www.infoq.com/news/2009/03/TDD-Improves-Quality
● Meetup groups
● http://www.meetup.com/Test-Driven-Developers-Bay-Area/

12. Questions