Automated tests, often referred to as unit tests or integration tests, or simply any tests that are conducted automatically, differentiate themselves from manual tests. Why do we implement automated tests? Primarily, they diminish routine work: no need to recollect the testing procedure for a module, the tests recall it. Just by pressing a button, a test suite composed of possibly hundreds or thousands of individual tests runs and reports any discrepancies found. Saving time is vital, but it’s not the sole benefit and, in my opinion, not the chief advantage of automated tests. Their fundamental role as a safety mechanism is far more crucial.
Ever heard of a safety net? According to Wikipedia, it is “a net used to protect people from harm after falling from heights.” You’ve likely seen it adorning buildings under construction or undergoing renovation. The crimson net in the image is a safety net.
Should construction laborers unintentionally plummet or misplace their tools, they won’t suffer a fatal fall or endanger individuals below. Does this assurance enhance their productivity? I’m inclined to believe it does. There’s no specific research on the comparison of productivity between workers aware of the safety net beneath them and those who know that an error could potentially cost them their lives or, worse, the life of an innocent child playing below. However, the outcome of such a study seems self-evident, I think.
This concept holds true for us as software developers. Modifying source code without automated tests in place is akin to working high above ground without a safety net: a single misstep can lead to server downtime, upset clients, monetary losses, and potentially even job loss. How would a programmer’s productivity fare in such conditions? Is it necessary to research this? Or is the answer as clear as it is for the construction workers?
To instill sufficient confidence, automated tests should not only be written and stored in a repository, but they should also be run automatically before every modification made to the trunk. You should be capable of executing them after each change you make locally while progressively developing the code. Then, you need to be certain that if you unintentionally overlook running them locally and push your branch for merging into the trunk, the automated merge pipeline will intercept you.
The more energy and resources you pour into fortifying your safety net — that is, the more thoroughly your tests cover your code – the more fruitful your work will be, the more secure you will feel while introducing new features or rectifying bugs. Simply stated, your coding will be quicker and superior. Just because you’re certain that you won’t compromise the work you completed the previous day.
The initial step when you embark on a new software project is to establish a safety net: you automate the build pipeline and craft a few elementary automated tests. You ensure they safeguard you. Only then do you commence coding. Question construction workers: are they permitted to begin their workday without a safety net? Certainly not. I presume it’s even unlawful. The same principle should apply to us programmers: coding devoid of the automated test safety net should be considered illicit.
When a customer reports a bug, it signifies a gap in the safety net. It’s insufficiently robust, which allowed the bug to land on your customer. What’s your initial step before rectifying the bug? You mend the safety net. You incorporate more automated tests, which will detect this bug in the future. Only then do you correct the bug.
I assert that the safety net of a software project is its most significant asset.
Yegor Bugayenko is founder and CEO of software engineering and management platform Zerocracy.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment