I have been in some weird conversation in which the agenda was to speak about HOW to do some backend tests and it was driven into IF we need any backend tests. This is quite embarassing, because it is an ongoing topic, and it is embarassing because when I was doing interviews, candidates are showing TDD skills (at least, at the best of their possibilities) but the feeling is that it is just something for interviews, because in real life the value of test is not clear at all.

This post does NOT want to be yet another post on theory about testing, but we need tests for 3 good reasons, and I mean THREE PRACTICAL REASONS, no theory here, just reality, every day advantage:

  • TO PROVE THAT THE CODE WORKS: wtf, devs. You are responsible of what you put in production! How can you feel confident in going in production without a good code review and TESTS?!?
  • TO DOCUMENT THE CODE: wtf devs! You won’t remember why you wrote the code in such way in a month. And in a month there may be a new dev. And if the new dev does not see tests, he WILL NOT PUT TESTS!!! How can you think that this won’t cause you huge issues?!? When you will wake up at 3AM for an incident, you will be really upset of the lack of tests that give you a direction on what it is happening
  • TO AVOID REGRESSIONS: if there is no test, you will have the same problem again, this is an easy truth and forecast.

Great, now look again at the 3 points above, and answer this question: who gets benefits from testing?!? DEVS!!! THE FUXXING DEVS!!! So why are we speaking about putting tests and the strongest disagreement is coming from devs?!? Well, because devs look at the short term quantity of work, and they don’t care of the distributed advantage of the approach. It is better to say that we closed a ticket faster than to have your colleague not being woken up by night. Even if that “colleague” may be you.

And that is part of the issue: the problem may be the culture. In a good culture, nobody should care of the length of a ticket (at least not more than of the quality of the same). In a good culture the quality should be first class citizen. In a good culture the milestones are agreed with devs. If a manager forces the delivery date (it happens everywhere, but it should be an exception), the dev can decide to sacrifice testing for making the delivery quicker. If that is the standard of the company, the company has a problem.

But ehy, we are paid for bringing quality in our work. It is a shared responsibility to keep the bar high. Everyone takes advantage of good tests, the question IF tests should be done is not acceptable, HOW they should be done can be the issue to solve, but not IF.

I am so disappointed that quality is impacted so much by… by what? Laziness? Pressure? What you save today in terms of time you will pay it 10 times later, and maybe by night, when you are not thinking of paying the price of your work.

Stay tuned!

Share