Testing that the code does what the code does

When unit testing goes wrong, what can we do to make it right? You may have noticed this effect, especially amongst the TDD zealots, often in legacy codebase. So many tests, doing so little. And every time I want to make a change, even just to refactor the code, there's loads of test failures! You hear yourself cry out "these tests are taking too long to fix". You're wading through treacle. Why is a test failing because I renamed a variable? What we're seeing here is what I call testing that the code does what the code does. Suffice to say I don't find it the best approach to testing. So in this session, let's go back to basics and discuss what unit tests are meant to be. We will develop techniques to get out of this hole, and how to maintain unit tests that empower rather than hinder refactoring. We will focus on observable outcomes not implemented internals. We'll blur the lines with integration testing in our quest to define what a unit is. Mocks, stubs, spies and doubles - let's learn when they should and shouldn't be used.