Let’s be honest, not everything can be tested so easily … No, testing is not a simple task, especially in a situation where the code that has been tested is overengineering. Sometimes testing such a type of software is not possible automatically. Why? For one simple reason, we are not always able to atomically put the application into the state that the user puts it in.

Jumping into ad-hoc testing can hurt. Why? Because first, you should have some practice, often quite a lot, so-called experience so as not to crash into the wall. The term testability should be used for a thorough understanding of the point.

In several projects, I had the opportunity to participate in a situation in which when the project was coming to an end, all functionalities were programmed, the manager came and said that now is the time to automate the tests. This will speed up development in the future and help maintain the project. Everyone was happy right away, but the enthusiasm quickly faded. Why? Because it never worked, not because testing is difficult and requires constant practice, but because most of the functionality has been so concealed that it was not easy to get to. Writing the tests itself took much longer than the proverbial two sprints. It was the over-engineering code that made the work on writing automated tests very slow.

Let’s be honest: there is no such thing as over-tested code. There is no such thing as too much testable code. There is no such concept. But there is such a thing as code which testing will not bring anything new. Therefore, the best approach is to write tests together with creating functionality. You can immediately check if it works and how it works. What casinos were taken into account, what worked and why and what did not? It is immediately visible what the tests bring to the entire infrastructure. Otherwise, there is no point in writing tests. Usually, it becomes a much more demanding task due to prime mover risks, scope, the domain knowledge itself about the project, complexity, dependencies, regressions that can kill the time that is no longer there.

Software that has not been designed and written for testability will lose a lot of quality, and at the same time will be complicated, hard to rebuild. Making one change will crash multiple places simultaneously. I’ve been there, I’ve seen it. At the same time, it introduces many software vulnerabilities and gives +80 to their exploitation +30 to create an exploit.

It doesn’t claim that you can’t add tests after writing a lot of code, but it’s not always just a profit. Code refactoring can be very painful without automated testing itself. There are many additional bugs that we have had no idea about so far …

Reference:

  1. A few words about automation
  2. DevOps - why you should care?

My site is free of ads and trackers. Was this post helpful to you? Why not BuyMeACoffee