Will Your C++ Program Still Be Correct Next Year?
summary
A practical testing philosophy that treats tests as executable requirements, not just examples: a word-histogram example reveals real bugs, fixes, and design choices — moving from std::map to unordered_map breaks order-sensitive assertions so tests change to unordered-range checks; splitting implementation into a freestanding per-word function makes private logic testable; using doctest, Catch2, Google Test shows matchers, custom printers and death tests for preconditions; mocks are useful but overused; clear, focused tests catch regressions and guide better APIs.
AI-written summary · about
chapters (22)
- 0:00Introduction
- 3:16Test types purpose
- 10:16Tests document expectations
- 11:41Testing histogram with doctest
- 15:24Adding size and empty to histogram
- 17:11Given-when-then in tests
- 19:22Range equality with Catch2
- 23:03Performance with unordered_map
- 25:53Avoiding over-constrained tests
- 26:14Testing private functionality
- 31:24Testing helper functions
- 33:12Custom split versus ranges
- 34:30Preconditions without contracts
- 37:40Mocks for preconditions
- 41:31Violation handler parameters
- 44:02Rethinking remove and insert
- 46:36Good test characteristics
- 48:29Testing dogmas warning
- 50:18Never flaky tests
- 51:27Long-term correctness
- 52:14Old code lessons
- 52:37Recommended testing talks
related talks
56mWill your program still be correct next year?
01h 02mBack to Basics: C++ Testing
59mC++ Unit testing - the good, the bad & the ugly
01h 03mBack to Basics: Testing in C++
01h 01mBack to Basics: Debugging and Testing in C++ Software Development
52mNobody Can Program Correctly - Lessons From 20 Years of Debugging C++ Code
01h 01mBack to Basics: Test-driven Development
01h 04m“All Your Tests are Terrible..."