“Failing tests are proof of flaw, successful tests aren’t proof of anything”
Nicolas Rinaudo (Scala IO 2019)
Tsong Yueh Chen (Initial citation)
I think all developers heard about tests at some point, but few of us are actually implementing them. Surely we can earn time by not doing them on the short time, but trust me on the long run you will be happy to have them.
Testing is costing time …
I won’t say the opposite, yes writing tests is costing time. From my experience, for a new feature, at least 50% of the time is spent on this part.
This is one of the main drawbacks of testing. Sometimes you have to deliver really quickly the new features in production, so why taking more time to test the new features if they look good ? So yeah, the delivery in production is done, the client is happy, and everything seems perfect in the perfect world.
One other drawback is the motivation. It is not always interesting to test, from a developer point of view, because the feature is a really simple one. Everybody can easily understand it, so why increasing the time spent developing the feature ?
… until the moment it saves time and a lot more
Let’s assume everything goes well : the project is in production since multiple months, the client is happy, and so the manager is. And there SURPRISE ! A bug is detected by the client.
As often (not to say always), the client has no idea on what is happening, and how to reproduce this bug. So you have to go back in the code, check everything quickly, you don’t see anything wrong, the manager is putting pressure to quickly solve the bug. This can take a lot of time. Aaaaaand there it is ! You find the issue, quickly solve it, and you see it could have been easily avoided. You do a hotfix and you deliver in production.
A part of the crisis is now behind you, but the manager wants more explanation. What he really wants to know is if the project is responsible for an incomplete development ? Or were the specifications from the client not precise enough ? And there you go (or another member of the team), going back on the client specifications to answer the manager, and so even more time is spent.
Ultimately, you will always find the bug and fix it, but what will be the cost ? Here the cost is the time (and so money, because time spent on fixing the bug is not spent on the new features), the good atmosphere in the team (working under pressure is never good), but most of all it is the project image that is reflected to the client (the project contains bug).
Let’s say you wrote tests when developing the features, the bug could have been avoided (I am saying “could have” because in my opinion, it is impossible to have 100% flawless code, a bug can always happen). Hence, all the above costs would have been at least reduced.
A guarantee of non-regression
Tests are here as a guardian of the behaviour. When you develop a new functionality, it is easy to accidentally change the behaviour of previous features. They are here to be sure you are not doing side effects and “breaking” the initial behaviour. This non-regression is really useful when you work on a project of some years old, where everyone forgot the initial specifications.
A reflection of the specifications
I like to think “if this test is written, it means it was in the specifications”. Maybe it is because I am on the “tech side”, but when tests are well written I find it easier to read the specifications from them.
Moreover, writing tests can improve clients specifications, because you can think of some scenario the client did not think of. And what would you gain from this ? Time, money, and recognition from the client ! The client will see you are not just executors, but you are involved in its business and exchanges will be smoothlier, even when there is a bug.
A contract inside the project team
If you think tests only concerns developers, then sorry but you are wrong. Sure there are technical tests only for developers, but there are also functional tests. The latests are conceived by multiple people on the team : developers, but also more functional people like business analyst, product owner, or any other person depending on your project organization.
Let’s take one of the projects I worked on for instance. The business analysts are translating the client’s needs into functional tests cases, into a format decided by the whole team. This format is then almost integrated as-is into our testing framework, and here we go ! We have our functional test ready.
What I want to emphasis on is the fact that the tests are not the responsibility of one people, or just the developers. They are the responsibility of the whole team, and the whole team agrees on the functional scenarios implemented.
The stage is yours
I hope I could at least make you think differently about tests if you were against them. If you are a developer, remember the well behaviour of the code is your responsibility, not your manager’s. So even if your manager is against testing, you should try to convince him/her. If you fail to do so, at least try to implement some of them. One test is better than nothing !
There are multiple kind of tests (unitary, integration, …) existing. For some of them, I will go into more details in following articles.
Johann Morales 