Before I worked at my current company, my only experience of Test-driven development was in 'Testing week' at my coding bootcamp (Founders and Coders). We'd been encouraged to write our code starting with a test first, but I didn't really understand the benefit of it, and the time pressures of finishing our group projects by the end of the week soon got in the way of carrying on with robust testing in the subsequent weeks.
Testing in the real world
This all changed when I started at OakNorth. I was told that the engineers there had a 'strict TDD' policy. This became apparent when I was sent reading materials on 'red, green, refactor' in advance of my first technical interview there, which I was expected to emulate in the interview itself.
The premise of 'red, green, refactor' is:
Start with a failing test (red)
Make it pass (green)
Refactor the code to make it even better, while staying green
Once I got into my first few weeks at OakNorth, I realised what exactly 'strict TDD' meant. Every single piece of code you write is prefaced by writing a test first. If you submit any code for review that does not have a test associated with it, this is immediately picked up by your reviewers. The tests are embedded in the PR pipelines, and they only get through if all the tests are green. Pair-programming is the norm at OakNorth, and writing tests quickly becomes your habit and instinct when your pair partner is constantly asking 'what's the next test?' and 'how can we get this test green?' and 'yay, a failing test!'
It took me a while to see starting from a 'failure' as a good thing, but it soon became kind of addictive to chase those green ticks! It is certainly very satisfying to have a tangible outcome from your work: first there was nothing, then there was the idea of something that does not yet work (the red test, or failing code), and finally there is the working code that makes the test pass.
Seeing the benefits
Now a seasoned engineer with over a year of TDD experience under my belt, I can truly see the benefits of a test-driven approach, and even choose to apply TDD to my own projects outside work.
Tests set up your expectations for what your code should achieve. They set out the scope of the work we need to do, which helps us to think through the problem and determine the right solution, kind of like writing a plan up front.
- I find my head is a lot clearer once I have written the test and thought through what it is that I actually want my code to do, rather than plunging straight in and hoping for the best
Developer productivity is improved, as we are forced to work in smaller steps. This keeps us focussed on the most important work at hand, and allows us to provide value sooner.
Tests act as internal documentation for developers. The first thing I do when reading a new area of the codebase, or reviewing someone else's PR, is look at their tests. These should give me a quick overview of what their code is trying to do, and what their expectations are.
Tests help build quality into the work we do, rather than accruing tech debt or cleaning up code as an after-thought. The 'refactor' stage of 'red, green, refactor' is indicative of this approach. It gives us the confidence to improve the code while ensuring that the experience for end-users is not compromised.
With a comprehensive set of tests, we can have more confidence in the quality of our code, and feel empowered to make changes in the future without fear of causing a regression.
Testing 'outside in', i.e. testing the code in the same way that a user might interact with it, allows us to ensure that the code we build actually meets the requirements of the end users.
- E.g. you might test that a form when filled in enables a button and navigates to another screen when pressed - your test acts as a user would.
A personal transformation
I've grown to love testing so much, that I now co-lead the Testing Guild at work! We write docs on testing best practises, improve test infrastructure to make the dev experience nicer, and run workshops on how to make the most out of testing at work.
Here are some of the things we advise:
Write atomic tests: each test should focus on a specific behaviour or functionality. Keep them small and focussed, addressing a single aspect of the code. This improves test readability, maintainability and allows for easier debugging.
Write tests for edge-cases: consider possible inputs or scenarios that lie at the extremes, as this is where bugs may be found.
Refactor regularly!