Sometimes it seems that we simply go from one extreme to another. Once upon a time developers didn’t bother to write tests. Everything was tested manually. When changes were made the whole thing would need to be manually tested again. Sometimes we used test scripts, other times we just played around trying to break functionally. And then we couldn’t remember what we had done to break it! Managers would roll their eyes in frustration when developers talked about writing unit tests.
I was working with a company recently where we were using Xunit as our test framework, NSubstitute for mocks, stubs etc and we ran our tests using NCrunch whilst developing in Visual Studio. At one point during the project we noticed that some of our unit tests were failing intermittently. This is more common in longer running integration tests but not so common in unit tests. When we do see this behaviour in unit tests the cause is often shared state being accessed when unit tests are being run in parallel.
I first learnt about writing unit tests following a project where we missed the deadline and spent far too long fixing and then refixing the code. I became frustrated that we would fix one thing and then something else would go wrong. When I saw how tools like NUnit and Rhino Mocks gave me the confidence to fix bugs and refactor it genuinely changed my working life. On my next project I determined to write tests as I went along and to be honest I’ve never looked back.