Three reasons why you should be writing tests
Writing tests for my code is one of those things I wish I had learnt earlier in my career. I come from the academic world where usually only one rule stands for coding: “If it looks good to you then ship it”.
Unfortunately (or fortunately) the same does not stand in tech companies, where code must be of production quality and, more importantly, the code you write must be easily understandable by everyone (included an older you).
The immediate benefit of writing tests is that, well, your code is tested. A well-defined series of tests, covering all the major corner cases, will leave your code with high chances of being bug-free. Apart from the obvious, tests also serve a second often overlooked purpose, which leads us to the first why of this article.
1. Tests protect your code.
Writing tests is crucial in an environment where the code base is shared and everyone gets to modify, expand and improve other people’s code. Tests will prevent anyone from breaking or mess up your code. This is particularly true if you use an untyped language such as Python. Tests will guarantee, for example, that the interface you engineered cannot be changed in a possibly destructive and not retro-compatible way. There is a golden rule in this regard: “if I modify and break your code it’s probably your fault, if there are tests proving that I broke it then it’s my fault”.
2. Tests make you a better software engineer.
The golden rule for well written functions is “a function should do one and one thing only (and do it good, I would append)”. This rule can be rewritten as “a function should be easy to test”. The simpler the function the simpler it will be for you to write a test for it. Writing tests will instantly make you understand if your code is well designed and implemented, if you are struggling with writing a test it is probably not. That’s why (even without falling into test-driven programming paradigms) you should be writing tests WHILE you are writing your code. One beginners’ mistake it is thinking “I’ll just rush through my code and then write my tests later”. This approach, which apparently leads to a higher productivity (intended as number of lines of code shipped over time), will possibly result in a recipe for failure and a critic drop (later on) in productivity. Usually coders moving really fast at the beginning can find themselves proceeding at a snail’s pace due to owning a messy codebase (as shown in the figure).
Writing test together with your code will force you to think about what your are writing, hardly resulting in badly engineered code. You are testing your code anyway while you write it, so, instead of writing (and deleting) testing code, just write proper tests from the get go.
3. Tests make you better at managing your pull requests (PRs).
“I’m wearing my coder’s hat, I’m in the zone”
How many times did we think this? You are grinding line after line, you wrote that complicated bit of (not tested) code which is now ready to be reviewed and merged. You open a PR and you realise it is 1300 lines of code long (vendored code not included). You feel bad for the poor souls who will have to review it, so you you close the PR and you start to chunk it up in multiple ones. Obviously this is not a good practice. Writing tests will force you to think more modularly about your code, making it clear when you should stop and ship the bit of code you wrote. Moreover, tests (if written together with the code) will increase the number of lines of code you ship, this will force you to open multiple PRs of a more manageable size from the beginning. Remember that this does not justify you to first write the code, ship it and then write and ship the tests for it. Pretty much nothing justifies you to do that.
