It is common knowledge that good software design practices involve unit testing your code. With more and more C++ code being executed at compile-time, it's necessary that we also write unit tests that check the validity at compile-time. However, this is no trivial matter. Just like with regular run-time code, we cannot reasonably claim that the code works in all its intended purposes unless it is tested and empirically shown to work. In very rare cases, a compiler's output can even vary between compile-time and run-time, given identical source code.
This talk will build up a compile-time-centric unit testing library, taking the audience on a tour of how and why to write compile-time unit tests. The "why" is straightforward and very important; as software professionals, we must test the validity of our code. The "how" is the fun part. Triggering a conditional miscompile is easy, but we all know that C++ compiler output can get notoriously unruly upon hitting errors. Therefore, we will explores ways to attain as much readability as possible in our diagnostics and error messages.
Currently, there are no popular C++ unit testing libraries that treat compile-time testing as a first-rate capability. As more and more code is written at compile-time, and as we move towards C++26 reflection, we still need to be testing all of our code. Let's explore the tools we need in order to ergonomically and scalably test our constexpr code.
View Slides
Braden Ganetsky serves as the Secretary of WG21, the ISO C++ committee. Braden graduated from the University of Manitoba with a degree in mechanical engineering, fueled by his passion for mechanical puzzles. During his final year of school, when all classes and activities were remote, he discovered C++ and has been hooked ever since. He interned as a C++ developer, which turned into a full time job, completing a successful pivot of his career. Now he spend his nights working on fun projects like parser combinators, constexpr unit testing, and getting involved in the C++ community.