Test First vs Last: Disappearing Rewards and Present Bias
Exploring how present bias and reduced rewards impact the test-last approach
This is the latest issue of my newsletter series, ‘Test First vs Last’, where we’ll explore how the sequence of writing tests affects our minds. The full context of this series can be found in the introduction post.
In my previous essay, Task Aversion and Confirmation Bias, I wrote about how I may experience aversion when writing tests:
After all, I’m done with the change, why bother writing tests? Suddenly, when I saw the written code, I felt it was hard to write tests. Maybe it’s not worth the effort. Oh, and that test framework I haven’t learned properly, it will be tough writing the test. I’m experiencing task aversion.
The aversion could come from many reasons, but aversion is not the only reason I might not write my test when I use the test-last approach. I’ll take an excerpt from Cecilie Vennevik’s blog post, A corner-cutter’s confession, as she brilliantly describes her experience (emphasis mine):
And yes, yes, I didn’t write any tests first. I know it would have made my work easier, and refactoring less error-prone. And it would have helped me out in the design process. But I knew what I needed to do (mostly)! And I could just boot up the app and test it manually - it was familiar and convenient!
What’s that? Did I write any tests after, then? Oh, no, I didn’t do that either. I’d, uh, already tested all the use cases manually by the time I finished. It felt like a waste of time not to merge the work and move on. Yes, I have no cheap way of catching regressions now, I know, I know. Can we move on?
Because there’s so much to move on to. I can’t afford to feel like I’m slow. There’s so many more things to do! Important things! Features! Stories! Bugs! Pull requests! The board is so long and the days are so short and I need to do my part.
Test-last may induce present bias
I have a higher probability of not writing a test when I practise the test-last approach too, just like what’s been illustrated in the excerpt. You might think what Cecilie or I would do to be lazy, but I prefer to make an argument that we’re delivering more value if we skip tests. The present bias influences us.
Present bias is our tendency to overvalue immediate rewards and undervalue long-term consequences. We tend to choose what we can do now that rewards us immediately rather than what can give us a larger reward in the future.
When it comes to writing a test, there are two types of rewards that you can get:
Instant reward - You know your change satisfies the expected behaviours
Delayed reward - You know your change breaks the existing behaviours
When I practice the test-last approach, I tend to test my change manually. This manual test will make the instant reward disappear because I understand that my change is working. This is not only happening for frontend development but also valid for backend development, where I would pull up an API client, like Postman, to test my changes.
Could the delayed reward be a good reason to write the test last? I’m not sure. My job as a software engineer is to deliver value to my customers, and that value can now be delivered because my change is done. Given the options to work on new features or write tests? I choose to work on new features!
The delayed reward of writing a test, to know that my future change may break an existing behaviour, regardless of how large the reward is, is seemingly small now compared to delivering a new feature.
To battle the present bias, you must draw rigour and discipline in your work. The leadership team may mandate that you write a test, therefore, it’s part of your performance goal, giving you an extrinsic reward. I’ll dread writing the test even more, as extrinsic rewards do not drive me.
Test-first rewards by design
When I practice the test-first approach (or TDD), I’m incentivised with the instant reward, writing my test so that I know my change satisfies the expected behaviour. Call me cheap, but I feel joy seeing my test turning green. It’s incredibly rewarding. It’s possibly the same kind of instant reward I get when I do manual tests in the test-last approach.
The delayed reward comes automatically in the test-first approach. Given that you have written the test, that will also benefit you in the future. Win-win.
Conclusion
When practising the test-last approach, the incentive from the intrinsic rewards perspective seems to disappear. Practice the test-first approach, and you may feel more rewarded when writing the test, both instantly and in the long run.
So far, in this series, I seem to have a strong bias towards the test-first approach regardless of how objective I tried to be, and I’m not happy with that. In the next essay, I’ll focus on one downside of the test-first approach.