Unit tests are now considered to be one of the foundational practices in modern software development. There are excellent talks and resources for getting started, and no end of good advice on how to write unit tests and what ideal tests should look like. Unit tests should be correct, complete, readable, resilient, and so forth.
But in real life, it's rarely possible to meet all these goals at the same time, and some situations make writing unit tests difficult or impossible. Existing or legacy code may not have been written with testing in mind; or "correct" results may not be well defined; or the code under test may rely on external services of hardware.
This talk reviews some of the most common "Plan B" techniques for tackling the more challenging unit testing situations. Topics covered will include
* White box testing: how to white box, when to white box test, and how to recover afterwards
* Abstract classes don't exist but we have to test them anyway.
* You can't test it without refactoring it, but you can't refactor without tests: cutting the legacy code gordian knot.
* It's probably right but we can't prove it, now what?
* It just failed: was it the code, the test, or some other part of reality?
Most techniques will first throw away some of the good advice we already have,
ALL TALK SESSIONS CAN BE ACCESSED FROM THE MAIN LOBBY:
https://cppcon.digital-medium.co.uk/
