I have to advise a training on unit testing in my company.
I would like to show a striking, real-life example of an unexpected regression not caught by compilation (of course) but detectable with unit testing.
Something more like a seemingly valid change that in fact cause a regression in another part of the program.
Would you share your unit testing epic-win stories ?
(Target language is C++, networked distributed application, but any good example will do)
Personally, I actually value the unit tests more at the point of creation, in their ability to force the developer to think about the code they have written, and to validate how they think their code behaves.
When a historic unit test breaks, in my experience it is usually has been because of an intended functionality or design change, and that the unit test has to be rewritten to reflect the new code. Whilst the rare (perhaps 1 in 20) occasions where they have caught a bug quickly is valuable, the act of forcing a developer to prove that their new code behaves the way they think it does adds much more value to the code base.
IMHO the value of unit tests can be understood most clearly whenever you have to create reusable libraries, especially when those libs are generic, with only few or no dependencies to other parts of the system.
Think of a mathematical library (for example, for vector or matrix operations, for graphs, or for graphical calculations). Those kind of things are often good unit-testable, and it should be clear that, once such a lib is used in a dozen programs or so, changing something internally in that lib will mean you will have to test a lot more of those programs again, opposed to the situation if you have a unit test suite available with a high coverage.
There are also some good videos of Brett L. Schuchert, showing live TDD coding, for example, this one for C++ or this one for Java, maybe you find them helpful.
Sounds like you are trying to 'sell' unit testing in your company. (Good for you!)
I am going to risk being hated here, but it sounds like you youself might not be 100% clear on all the benefits of writing unit tests. As other answers have pointed out, there are many reasons unit tests are extremely useful (sometimes even necessary) other than catching bugs that the compiler did not catch.
I suggest getting familiar with all the benefits and designing my demo accordingly.
Here are some quick things I would talk about/demo (not in any special order):
Quick validation that unit of code works without having to actually run it in its intended environment. This is extremely crucial when it takes 5 min to build your project, 10 min to deploy it and half an hour to try to find the scenario when the code actually runs to validate that it 'works'.
Validation of code that would be extremely hard to test in its intended environment. A huge percentage of the code we write is handling error conditions or conditions that only happen in certain strange circumstances. These conditions are very hard to reproduce in real life, therefore require special attention to test.
Validating 'library' code. If you are writing code that others consume, your only way of validating would be to write another 'project' that consumes and drives it. Unit tests give you a high confidence that your code works without having to use a project that drives your code to test it or to write a 'tester' app yourself.
TDD. Test Driven Development is a fairly new way of thinking about unit tests. When exercising TDD developers write the tests first, then code afterwards. TDD can improve your code by only writing code that satisfies passing your tests. There is much debate about this topic and myself used it extremely successfully in certain situations, but not so successfully in others (context dependent IMHO).
Tests document your code. Many times tests are the most updated documentation on how your code is supposed to behave. How many times do you look for an already existing piece of code that exercises a class/method just to see how you are supposed to use it? Well unit tests give you just that.
Code breakage. Yes, unit tests do catch bugs. However I find that they most often catch bugs during development. I write the code, then I turn around to write the test and this is the phase when I catch most bugs.
I am sure there are more to mention here so you should do more research before your training. One more thing. It is hard to find examples when unit tests 'saved the day in a big way' because they catch bugs during development and very silently most of the times. You only really understand their benefits when you have been writing them for a while to see how they save the day (on a daily basis).
I would compare them to exercising. It is hard to find a case when daily exercise saved someone from having cancer or a heart attack. But you do know deep down that it is necessary to live a long and healthy life.
(yes I'm answering my own question - just happened to remember a good example)
I remember finding and busting some tricky C++ smart-pointers reference loop with the combination of unit-testing + valgrind.
Seeing some leaks in unit (= limited) tests make it easier to diagnose who is holding the unexpected reference than in the full running code. (In this case, it was a parent/children relationship with both needing a shared pointer on the other. Broken using weak_ptr)
