This post is secod part of my Back to basics: on testing series.
Developers writing tests
People new to software, or coming from organizations where all testing is done by dedicated people often find the idea of developers doing testing bizarre.
After all, we’re the highly trained, educated professionals. We get payed to do the hard bits. Clicking around the UI to see if a label is misaligned or an app crashed surely should be delegated to somebody else, outsourced even.
Truth is, there are various kinds of tests, and while there is value in UI tasting (automated or not) we’ll concetrate at somethig else first.
You write the tests for your future self
The idea of developers writing tests came not from academia but from the field. From people who spent years developing successful software. And as you get out there, and start working with teams of people, on real life big systems that solve real problems, you realise that some things you belived (or in fact were taught) to be true, are not.
We’ll get into the details as we progress with this series, but let’s start with the biggest one:
The code is written, and read, and read, and read and read some more and modified, and read, and modified again, and read some more again and then few months later read yet again and again
You may notice there’s much more reading than writing there. That is true for most code – you don’t just write and forget it, like is the case with coding assignments at unversity. Real-life code is long lived, often expanded and modified and commonly the person doing the expanding is not the person who originally wrote the code. In fact the original author may have already moved on to work elsewhere.
- How do you know what the code does?
- How do you know where to make the change?
- How do you know your change didn’t break any of the assumptions that code interacting with the bit you changed makse about it?
- How do you know the change you made works the way you wanted it to?
- How do you know the API you created (in other words the public methods) are easy to use and will make sense to the other developers using it (that may also be you few weeks from now!).
These are the reasons for writing tests. Tests are the most economical way of ensuring the change you will make two months from now fit in the design constrants you designed today. Tests are the fastest way for other developers (or again, future you) to get a feel of how a piece of code works; what it does, and how you’re supposed to use it.
Don’t just take my word for it
In the next part of the series we’ll start looking at actual code, writing some tests, and explaining the concepts around them.
Until then, if you have any questions, or suggestions as to what to cover in future posts of the series, feel free to leave a comment.