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.
Senior Developer, Tesco Bank
Sam is fascinated with making teams work together better, and keeping up with the ever-changing world of software engineering. He has a decade's worth of experience in highly-regulated environments, across finance, biotech and energy. Whether it's mobile, desktop, web, server or cloud, he has the battle scars. In his spare time, he can run a fine game of Dungeons and Dragons!