Testing and automated tests.

"Testing it's not dependable on time constraints, feature delivery is." 

There are a great number of test disciplines. The text will focus on automated tests in software development.

So I could use a "should" instead of an imperative tone in the title but it seems to get the gap between "I wish" and reality even bigger.

Normally, things that stay behind are the ones sacrificed when time gets shorter. The importance of testing implemented/changed chunks of code properly, are difficult when proper planning is done, when time pressure overtakes teams priorities this is neglected at all levels (management and developing).

Nowadays, any development framework that wants to honor the title and aspires to completeness, have to include a decent test architecture, facilitators, focus on test reliability and efficiency creating them.
 

The questions I usually make when I’m thinking about a solution to a problem are:

• What I want this to do?
• How will I test it?
• What can I automatize?
• How do I implement this?

Thinking on the implementation after thinking what to test and how to automate it, will influence the implementation. Hum, where did I hear this (core) concept? TDD perhaps :D


The main goal of the article isn't to evangelize on any form of TDD, BDD or other test driven philosophy. They are all, in my opinion, objectives, goals, the end journey, the holy grail of perfection frontier conditions awareness.


It's hard to tell how the journey is made, at least to create a full blown guide that can cover a large percentage of use cases in how to do it.

I can think in a few common reasons for not doing it:

 Status Quo: always did like this and I’ve presented results.

True, the first main goal is to deliver. That’s an universal truth. No point in being a process expert or code a masterpiece if it doesn't work. But if something works, it must be maintained and even having the same team or a good handover process so knowledge of the project is continuously passed, one day there will be parts of the code that will be like a foggy day. By that time the little, tiny, less coverage situation test, will be a blessing. And Why? because it is something that is tested and less a thing hidden to be spotted in production mode just because we didn't have a way to verify changes impact in our code.

 

 It's difficult to achieve completeness.

True again, I may add that the more complex the system, the more far we are from getting it. Nevertheless it's not a reason for not doing it. If you have a bicycle to take you half way, you would prefer to go all on foot because it cannot reach what you intended (please, it's just a metaphor...don't counterexample with mountain climbing and things like that :D)

Time Consuming and harsh learning curve.

True again but I will say that the quality in the end will, for sure, compensate.

When I bought my bicycle, I knew that it would eventually have some kind of malfunction or damage. Maybe some defect will be detected. But I expect that it was tested, at least the brake system. If someone showed me a bike and the wheels weren't there, I wouldn't buy it. If on the first ride the pedals were stuck and someone justified that with a "maybe the pedal is the wrong model” I would be very upset because clearly no one tested the use of that model.

So, testing and in this case automatic tests, raises the confidence in implemented changes and the quality delivered. It also benefits everyone by reducing uncertainty in each delivery.


In my case, focusing on how to test solutions in an automated way, made me a better and a more responsible professional: yes, thinking in consequences and how to prevent them gives us a scope of awareness that is important for understanding the problems. Hope to continue in this path and to see and help more to do it so (wow...seemed like a cult 😂).

Alcindo - Software Engineer