Revolutionize Automation by Adapting Test-Driven Development

The Software Development industry is always trying to stay one step ahead because the future is full of magical possibilities, and defined by how we think today. A novel vision that closes the gap between development and testing in this industry is Test-Driven Development (TDD). The future lies in how fast we succeed and move ahead, and fast success depends on how fast we fail. To enable our industry to fail fast — and shift left into the timeline, development, and testing — both segments have embraced different ways of automation. TDD is one such automation technique, which opens the window of possibilities.

TDD is a process that relies on the repetition of a very short development cycle. Requirements are turned into very specific test cases, then the code is improved so that the tests pass. This process is opposed to the classic development process, which allows code to be added that is not proven to meet requirements. Below are the basics of TDD process:

1. Add a test: The developer writes a test that defines a function or improvements of a function, which should be very succinct.
2. Run all tests and see if the new test fails: This validates that the new test does not pass without requiring new code, and rules out the possibility that the new test is flawed and will always pass.
3. Write the code: The developer writes code that causes the test to pass. The new code written at this stage is not perfect and may pass the test in an inelegant way. It will be improved and honed in Step 5.
4. Run tests: If all test cases pass, the developer can be confident that the new code meets the test requirements and does not break or degrade any existing features. If they do not, the new code must be adjusted until they do.
5. Refactor code: The growing code base must be cleaned up regularly during TDD. New code can be moved from where it was convenient for passing a test to where it more logically belongs. Object, class, module, variable and method names should clearly represent their current purpose and use to improve maintainability.
6. Repeat: Starting with another new test, the cycle is then repeated to push forward the functionality. If new code does not rapidly satisfy a new test, or other tests fail unexpectedly, the programmer should undo or revert in preference to excessive debugging.

Adapting TDD into the traditional software development lifecycle has its benefits in terms of cost savings, early bug-finding and rapid releases. On the other hand, the blurred line of responsibility where developers become the QA may pose threat to the traditional definition of roles within the team.

Personally, adapting to TDD had been a boon in my DevOps team. DevOps, being essentially a support team, does not have any designated developer or QA on the team. However, in the era of automation, our DevOps team has come up with game-changing ideas of automating processes into tools and turning services into products. In a period of four to five years, we have evolved from manual monitoring, manual communication and manual server reset, because the team has harnessed the ideas and created many in-house tools that were vastly accepted into the daily lives of developers and QA.

To develop the in-house tools, test them properly, release them, run beta testing, track bugs and release fixes and enhancements our team needed major change from within. Our QA turned into BAs, techies turned into developers and developers turned into QA and with the adaptation of TDD — all with a significantly small learning curve. The responsibilities of the specific roles were assimilated into the evolved roles effortlessly. TDD has now become the go-to technique when we need to merge teams, merge responsibilities, increase accountability in the team and, most importantly, help clients to shape their budget, channelize the budget in right direction and if necessary, help in cost cutting.

With COVID-19 hitting the global economy hard, like every tough time in the past, the human race is again forced to accept and adapt to a different vision of the future. And I believe TDD could be the technique that can help bring stability in the journey of automation.

With TDD being the novel step to automation, we are now closer to un-tapping the potential of technology. Arthur C. Clarke once wrote: “Any sufficiently advanced technology is indistinguishable from magic.” Automation has proven to be the key to create that magic. The sooner we embrace and adapt to this changing industry, the faster we become one with the magic.

Read more about our DevOps processes and solutions.