[cyberneticcook]

I think it's dangerous to rely solely on a unit test suite to guarantee the correctness of your program. Each unit-tested component may pass its own tests, but that doesn't guarantee that by interacting with other (present and future) components it won't exhibit any bug. I guess immutability would go a long way forward in realizing this guarantee, but I've never had the pleasure of working on a software where each component was truly immutable and independent of each other.

[jarrett]

Very true. Here's an example of a bug that has bitten me more than once, has everything to do with immutability, and isn't reasonably within the scope of traditional testing tools:

A crucial class writes files to a certain folder. The test sandbox provides such a folder, and the class knows to use that folder when it's running in test mode. Obviously, the production environment is also supposed to provide that folder. But oops, it doesn't!

The tests exercised writing a file to disk, the tests were all green, and the system crashed anyway.

[bulte-rs]

And this is - IMO - where the magic happens. It's somewhat doable to "waterproof" your unit tests; but getting every (possible? Required? Anticopated?) interaction tested?

Magic.

I'm not saying tests are evil, I actually love my test suites. But as always; as soon as someone uses ALWAYS and/or NEVER, those tiny hairs in the back of my neck do a sort of wave and I try to ignore their message, which is a shame since (in this saga) both Uncle Bob and Nephew David have good advice to offer.

As for immutability; add in referential transparency, static ish typing and you've got yourself a nice development setup ;)

[MartinCron]

I always progressively test at different levels before insta-deploy, and run a set of "is this still OK" tests against production post-deploy.

Unit tests are at the heart of the test gauntlet, but absolutely can't be trusted by themselves.