Unit 5: Unit Testing Robot Code With JUnit

A rule written in Java is only a claim about what the program should do until you exercise it with known inputs. This chapter introduces JUnit testing in the same environment WPILib Java projects use, then pushes beyond the easy cases into boundaries, deliberate failures, regression tests, exceptions, and state-preservation checks.

Chapter question

How can a test suite turn robot-component requirements into repeatable software evidence without pretending those tests prove the entire robot system works?

What you will understand

You will learn how JUnit 5 test methods, assertions, boundary-value analysis, expected exceptions, regression tests, test isolation, and WPILib desktop testing work together. You will also learn why a test failure is evidence worth preserving rather than something to erase.

What you will do

You will write JUnit tests for ObstacleGuard and ValidatedRangeSensor, test values immediately around important boundaries, deliberately introduce a <= defect, record the failed assertion, repair the production code, rerun the same regression test, and compare the software result with a separate controlled ROS 2 graph observation.

What you will produce

Your final artifact is a Component Test Record containing the requirement, test matrix, executable JUnit structure, one preserved failing result and repair, exception tests, state-preservation evidence, and a separate ROS 2 graph record.

How the week connects

Unit 4 gave you component classes, interfaces, multiple implementations, exceptions, and clean boundaries. Week 9 uses those boundaries to test behavior with controlled inputs. Week 10 will take the next step: when something does fail at runtime, the software needs useful logs and a disciplined diagnosis process.

Key vocabulary

unit test, JUnit, @Test, assertion, expected, actual, boundary value, regression test, assertThrows, test isolation, simulation, test matrix

Approximate time

About 210 minutes for the five lessons, lab, and wrap-up. Students with a local WPILib Java project can execute the tests through WPILib's desktop test workflow; the reader lane provides clearly labeled supplied results when local execution is unavailable.

Final evidence required

A complete Component Test Record showing tests at and around the caution boundary, validation tests around the sensor interval, one intentional failure preserved before repair, the successful rerun of the same regression test, and a clear boundary between JUnit/WPILib test evidence, ROS 2 graph evidence, and untested physical behavior.