All paths

Software design and testing

How teams keep firmware right as it grows: readable code, modules behind narrow interfaces, fakes, tests on boot, test-first fixes, safe refactors and code review. Ends with a messy sketch refactored under test.

Arduino Uno R3Free7 lessons7 h4 chapters4,060 XPCoding · Expert+400 XP

0 of 7 done

What you will build

3 projects, built step by step

7 lessons in 4 chapters, about 7 hours on a simulated Arduino Uno R3. Free, in your browser, every step checked by the simulator.

Chapter 1 project

Modules and interfaces

A thermostat that only knows a TempSensor interface: a real TMP36 and a fake behind the same door, a rehearsal with the fake on boot, a move into sensor.h, and a calibration added without touching the thermostat.

Open it in the simulator
Chapter 2 project

Test-driven fixes

A bug report against a countdown that passes all its tests: reproduce it on the hardware, pin it to one pure function, write the test that fails, fix it, triangulate the edges, and close the report.

Open it in the simulator
Chapter 3 project

Code review and git, explained

Commits, branches, diffs and pull requests explained properly, then a real review: a teammate's pull request with a millis() rollover, an off-by-one and an int overflow, each caught by a checklist question and proven fixed by the self-test.

Open it in the simulator
The map

Chapter by chapter

Each lesson opens when the one before it is done, and each chapter ends in a project.

Chapter 1

Code people can read

Names, one job per function, and modules behind a narrow interface.

  1. Open430 XP

    Clean functions and naming

    A thermostat sketch that works and lies: one-letter names, magic numbers that drifted apart, one loop doing four jobs. Name the numbers, give each job a function, and read loop() like a table of contents.

    0 of 7 steps

  2. ProjectLocked760 XP

    Modules and interfaces

    A thermostat that only knows a TempSensor interface: a real TMP36 and a fake behind the same door, a rehearsal with the fake on boot, a move into sensor.h, and a calibration added without touching the thermostat.

    0 of 6 steps

Chapter 2

Tests that run themselves

A harness in twenty lines, then bugs fixed test first.

  1. Locked430 XP

    Unit tests with plain asserts

    A test harness in twenty lines: a CHECK macro that prints PASS or FAIL with the line and the condition, a summary line and a red or green lamp. Test the edges, meet a real failure, fix it, and switch the tests off for a release.

    0 of 7 steps

  2. ProjectLocked860 XP

    Test-driven fixes

    A bug report against a countdown that passes all its tests: reproduce it on the hardware, pin it to one pure function, write the test that fails, fix it, triangulate the edges, and close the report.

    0 of 7 steps

Chapter 3

Changing code safely

Refactors under test, and the review and git habits of a team.

  1. Locked430 XP

    Refactoring

    A Beaufort wind scale as an if chain and a switch, reshaped into two tables with its tests green after every step: replace a conditional with a table, prove the net catches a slip, extract a function, and add a feature in one line.

    0 of 7 steps

  2. ProjectLocked700 XP

    Code review and git, explained

    Commits, branches, diffs and pull requests explained properly, then a real review: a teammate's pull request with a millis() rollover, an off-by-one and an int overflow, each caught by a checklist question and proven fixed by the self-test.

    0 of 6 steps

Chapter 4

Boss

A messy dice sketch, fixed test first and refactored under its own self-test.

  1. Locked450 XP

    Boss: refactor the dice, tests green

    The gallery's electronic dice after a game night of quick fixes: one-letter names, an if chain, pasted code and a bug report. Fix the bug test first, then refactor it clean, one step at a time, with the self-test saying all pass after every run.

    0 of 8 steps

Syllabus

Every lesson in the course

All 7 lessons, in order, each with what it covers. Any of them opens in the editor right away.

Chapter 1

Code people can read

  1. Clean functions and namingA thermostat sketch that works and lies: one-letter names, magic numbers that drifted apart, one loop doing four jobs. Name the numbers, give each job a function, and read loop() like a table of contents.
  2. Modules and interfacesA thermostat that only knows a TempSensor interface: a real TMP36 and a fake behind the same door, a rehearsal with the fake on boot, a move into sensor.h, and a calibration added without touching the thermostat.
Chapter 2

Tests that run themselves

  1. Unit tests with plain assertsA test harness in twenty lines: a CHECK macro that prints PASS or FAIL with the line and the condition, a summary line and a red or green lamp. Test the edges, meet a real failure, fix it, and switch the tests off for a release.
  2. Test-driven fixesA bug report against a countdown that passes all its tests: reproduce it on the hardware, pin it to one pure function, write the test that fails, fix it, triangulate the edges, and close the report.
Chapter 3

Changing code safely

  1. RefactoringA Beaufort wind scale as an if chain and a switch, reshaped into two tables with its tests green after every step: replace a conditional with a table, prove the net catches a slip, extract a function, and add a feature in one line.
  2. Code review and git, explainedCommits, branches, diffs and pull requests explained properly, then a real review: a teammate's pull request with a millis() rollover, an off-by-one and an int overflow, each caught by a checklist question and proven fixed by the self-test.
Chapter 4

Boss

  1. Boss: refactor the dice, tests greenThe gallery's electronic dice after a game night of quick fixes: one-letter names, an if chain, pasted code and a bug report. Fix the bug test first, then refactor it clean, one step at a time, with the self-test saying all pass after every run.
Keep going

The rest of your track

Software design and testing is part of the coding track, a ladder of courses from zero to expert.

Track

Coding track

Python and C++ from your first print to classes, tests and state machines. Every program runs on a simulated board, so a bug is something you can see.

See every course on the track
Kits

Build it on your bench too

Every lesson runs in the simulator with nothing to buy. When you want the real thing, these kits have the parts.

Have a kit already?

Find your kit

Pick the starter kit you own and run every lesson in its manual with the same parts on the same pins.

See every kit
Questions

About Software design and testing

Is Software design and testing free?

Yes. All 7 lessons of Software design and testing are free and run in your browser, with nothing to install and no parts to buy before you start.

Do I need a real Arduino Uno R3?

No. Every lesson runs on a simulated Arduino Uno R3 with its parts on the canvas, and the simulator checks each step as you go. When you want to build it for real, the same wiring and code work on a real board.

How long does Software design and testing take?

About 7 hours: 7 lessons in 4 chapters, each one a few short steps. Your progress is kept, so you can stop after any lesson and pick up where you left off.

What will I build?

Each chapter ends in a project that puts it together: Modules and interfaces, Test-driven fixes and Code review and git, explained.

Where do I start?

With "Clean functions and naming", and each lesson builds on the one before it. New to circuits? Electronics basics is the course that starts from zero.