Thanks for the talk. Regarding testing the tests.. Inspection is NOT the only mechanism. Once you have established a test for a behaviour, deliberately modify the testee such that the modifications change the behaviour outside its acceptance criteria. This can be as simple as reintroducing bugs or more insidious changes. The expectation is that the existing tests related to the behaviour fail. The main caveat to unit testing is the existence of well defined acceptance criteria, which in my experience is the biggest elephant in the room. Everyone wants effective testing, but not many go to the effort of defining what that means. Thanks again for the talk.
@@denvercppmeetup Yep sorry, this was just an initial reaction when I saw him. It was a good talk. I look around for c++ talks especially on constexpr. So I've seen constexpr all the things and such. So right at the start of the video I saw him and posted that. Maybe I shoulda deleted it.
52:00 I actually use the friend method quite often because it saved my ass from incorrect private methods more often than I can remember... This is especially true if your public method calls like 10 private ones... (This helps especially with finding the error faster.) 54:41 I want to cite Dijkstra here: "Program testing can be used show the presence of bugs, but never to show their absence!" And imo this further enhances my point for 52:00.
Yes, white box testing can be really handy. But it has its downsides, most of which don't become immediately apparent -- they are "software engineering" rather than "programming" issues, to use Titus Winters' terminology.
