Unit Testing & Other Embedded Software Catalysts

Dr. Surly's School Teaches Test Driven Development for Embedded & System Software in C So You Can Take Over the World.

4.3
(62 ratings)

Instead of using a simple lifetime average, Udemy calculates a
course's star rating by considering a number of different factors
such as the number of ratings, the age of ratings, and the
likelihood of fraudulent ratings.

How taking a course works

Discover

Learn

Master

Learn and practice real-world skills and achieve your goals.

About This Course

Published 2/2015
English

Course Description

Welcome to Dr. Surly's School for Mad Scientists!

Unit Testing and Test Driven Development help smart, capable developers like you create robust, reliable, and maintainable software. Apply these skills to embedded and system software, even in C, to improve your architecture and quality. Sleep soundly at night.

Learn concepts from Agile, XP, Scrum, and Lean practices for producing well designed, high quality, scope-managed, and self-documented code.

Utilize free open source tools like Unity and CMock in real-world scenarios. No toy examples.

Powerful Tools for your Development Toolbox

You will learn skills that have become staples in higher level languages but are sadly underutilized in the C space. In particular, you will learn to write unit tests in the uniquely challenging world of embedded and system software.

Curriculum

Welcome to our mad scientist lab. If you're going to take over the world some day, inevitably you're going to be building electronics and programming low level code. You may be insane, but you're not dumb. You're taking this course to learn structured and responsible testing practices for low-level code. We're going to be working in C and using open source tools like Unity and CMock to get you writing tests as soon as possible for a variety of example projects. You learn best by doing and so there's plenty of doing in this course.

If you want to know more about Dr. Surly, the patron saint of mad scientist firmware developers, you can read his much abridged life story. It's one page, and it's attached.

Unit testing embedded and system code is a relatively new development. In fact, the tool we use in this course was created at a time when many thought such things couldn't be done.

The nuts and bolts of Section 2 is to push off lots of yacking at you until later in favor of getting you writing tests as soon as possible. Don't worry. We will address your inevitable questions soon enough. Please be patient.

If you chose to use the web-based development sandbox we introduced in the previous lecture (our recommendation), in this lecture we walk you through that environment and how it will be used in the course. Together we will verify that your setup is working properly.

This lecture covers your options for asking questions not addressed in the course material. For instance, you may need help debugging issues in the previous step (lecture). Or, you may have specific technical or philosophical questions that arise during the rest of the course.

The testing setup we employ early on is easy to use and generally problem free. Our supplemental documents cover lots of issues and potential questions. But if you're stuck, you have several options for help.

In this lecture we guide you through developing a full set of unit tests for a real source code module! Along the way we show you how to think through just what exactly should be tested and then how to structure your unit tests to accomplish this.

In this lecture we explain what's happening under the hood of these testing tools and why the tools were designed the way they are. We break down a project's code in diagrams to show how your source and test code live separately but in harmony.

We get into the nitty gritty of how and where you actually run your executable unit tests:

Locally (native)

In a simulator

On target

And we address the scope of testing approaches:

Unit

Integration

System

For more on the fine details of unit, integration, and system testing, please see our supplemental "Extra Goodness" document (document archive attached to Lecture 4): What's the difference? Unit, Integration, and System Testing.

Lecture Appendix

If you want to really dig in to understand a testing framework like Unity:

In this lecture we walk you through creating a new embedded source module from scratch. You will begin building a real GPIO module and unit testing all the necessary register settings as you build up the code from requirements. You'll be developing the source and the tests together. We identify and demonstrate good practices as we go.

We introduce the concepts of Test-Driven Development and Behavior-Driven Development. Surprise! You've already been using these concepts. We explain their principles and many benefits… and how they apply to building up a suite of unit tests.

In this lecture we share useful resources on the concepts covered in the previous lecture. Additionally we point you to a variety of studies on and philosophical discussions about the value and tradeoffs of unit testing itself. With the materials of this lecture you will be able to speak intelligently to your colleagues about both the pros and cons of unit testing practice. We also assign some homework.

In this lecture we further develop the embedded GPIO module we began in this section and we pick up the pace a little. We continue demonstrating test-first and behavior-driven test development for additional pieces of the GPIO interface.

And, we specifically address good practices for working with:

Newly implemented but mostly blank functions

Error codes and conditions

Bounds checking

Registers are fairly simple—except when they're not. Different processors use different styles of register interaction and produce a variety of behaviors. See our supplemental document (attached in Lecture 4): Testing Special Cases for more perspective on testing tricky register interactions.

In this lecture we take a step back and discuss two important concepts underlying the decisions we've been making along the way:

Do the Simplest Thing That Could Possibly Work

Ya Ain’t Gonna Need It

These are powerful concepts that may feel a little wrong at first. We explain why they are a good way to work and how testing plays nice with these approaches. We then demonstrate them in action in testing the Init() function of our GPIO module.

In this lecture we work through a case that seems complicated on its surface. Our mantra of Simplest Thing That Could Possibly Work seems to lead us to call source functions in our unit tests that are outside the test case under development. We show how to think through decomposing these rather common cases into tests and also introduce setUp() and tearDown() within the testing framework.

In this lecture we walk through the development and testing of a State Machine module used to implement a protocol parser. We discuss and demonstrate how all our recently developed skills apply quite well to this sort of module.

We review all the work we've done in all the sections of our course and where it falls in the scheme of things. Go on towards world domination with your mad scientist plans.

For an in-depth look at testing special cases (e.g. main(), for() loops, various register setting scenarios), see our supplemental "Extra Goodness" document (in the archive attached to Lecture 4): Testing Special Cases. Heck, take a look at all the documents in the archive as they will address many issues we can't cover in the main course.

Students Who Viewed This Course Also Viewed

Loading

Loading

Loading

SHARE

Instructor Biography

Hi. I'm Mark. I've been developing awesome things with embedded software for 15 years and I help other people do the same. I've worked on self-guided lawnmowers, automotive electronics, color measurement devices, bluetooth beacons, and much more. I'm one of the creators of the open source tools Unity and CMock, which help people test C code. I'm one of the founders of Throw The Switch, an online community dedicated to making embedded software better.

Instructor Biography

Hi. I’m Mike. I've been working on crazy software projects for 15 years—everything from weather balloons to smart rear view mirrors to EEG-based versions of Pong to gesture-based security systems. I’m one of the creators of the open source tools Unity, CMock, and Ceedling that help people unit test C code. I’m also one of the founders of Throw The Switch, an online community dedicated to making embedded software better.

I have two bachelor's degrees in Electrical Engineering and Computer Science. At the moment I’m finishing my doctorate in Computer Science with a specialty in Human Computer Interaction. Before grad school I was a professional software developer for 12 years including a stint as a vice president of a contract software firm. I've trained numerous clients in Test Driven Development techniques including a Tier 1 auto supplier and an intelligence agency of the US Government.