CppCon 2024

If you've ever struggled to write tests for domain-specific functions with complicated, real-world inputs, this talk is for you!  We'll use the Motion Planning component in a self-driving stack as a case study (although you won't need any prior Motion Planning experience to follow the talk).  In building objects for our test inputs, we faced the classic dilemma.  If we make the objects simple, they're hardly meaningful, and the tests amount to little more than smoke tests.  If we try constructing more realistic objects, it takes tremendous amounts of boilerplate code (which obscures what is actually being tested) --- and what's worse, these finicky construction methods go stale and break easily as implementation details evolve.

There is a better way!  To find it, we take our inspiration from a (paraphrased) Kent Beck quote: "First, make the test easy.  (Warning: this may be hard!)  Then, write the easy test."  What this means is investing in full-fledged testing support libraries.  First, we build foundational domain-specific APIs: user-friendly paths, poses, and speed profiles.  Then, we provide APIs that bridge the gap between what the user pictures in their head when they want to write a test (a "scene"), and the data structures that represent that situation in the software (a sequence of planner input messages on different channels).  This "scene description" that the user writes is high level and doesn't depend on implementation details, so it resists going stale, as we'll illustrate with an example involving road construction zones.  On the implementation side, the problem decomposes beautifully: each planner input (map, actors, etc.) can be constructed from the information in the scene description, independently of all other inputs, helped along by the paths and speed profiles.

These ideas could be implemented in many languages, but C++ particularly excels at delivering performance, robustness, and flexible, natural APIs.  As an example, we'll explain the benefits of describing each planner input with a "smart" tag type, containing both the name and the message type.  On the implementation side, variadic templates make it easy to conjure up containers and interfaces that operate on "all planner inputs", eliminating the risk of forgetting to update some callsite when we add a new one.  On the interface side, end users see none of this complexity: they can simply use _instances_ of these tag types as "indexes" into these containers in a natural way.  This fluency and power makes more complicated test cases possible: it becomes easy to select and "tweak" any planner input to ensure we respond correctly when the messages are malformed, delayed, or absent.  Overall, we hope our experience enabling high-quality Motion Planning testing at scale will have lessons that can be adapted to a variety of other domains.