In part 1 of this series, we explored the fundamentals of Test Driven Development. After wrapping our heads around the principles and understanding the origins of TDD we will now look into applying TDD.
Adoption of TDD.
Test-Drive Development is effective and it works. There’s a catch though. Not all teams can jump right into it and start following the processes defined by Test-Drive Development(TDD). It is not easy to Convert your teams working in traditional programming processes trying to figure out the arcane code they have written. The challenge doesn’t just stop at the teams, convincing management about the change in approach in application development is another hurdle all by itself. Understanding Test-Driven Development is not the same as Integration testing is paramount to the adoption of Test-Driven Development (TDD).
Every time you talk to a team-lead they will usually bring up the point that they are already in the middle of their development it is an impossible task for them to just jump ship and start practicing TDD. The change isn’t about shifting to a Test-driven approach right away. The team can always start to write tests and run the tests manually if the team doesn’t have the privilege or the capacity to automate the tests. By defining and running tests manually the team could still cover their bases in terms of unit testing their code.
When you talk to a traditional developer or an uninitiated in the ways of TDD, they will question you about “why they should make the shift?”, “Why worry about the overhead?”. The most direct approach to answer the question is to show how TDD visibly improves the quality and the standard of code.
The Challenge
A majority of software or application development is done to cater to a competitive market. Execs invariably promise a short timeline, to compete with the other players in their specific domains. This thought process metastasizes and the development teams have tunnel vision to deliver products, applications in our case, as fast as possible. The teams focus on a speedy approach to maintain the status quo always corrupts the process and always leads to jugaads(Hacks) as productionable solutions.
Another challenge is the mindset of the development team. Traditional developers have to adopt a completely different approach to what they were used to. The code that is written with the traditional approach in mind is most often not testable. This is why teams don't test their code.
Change is hard because people overestimate the value of what they have and underestimate the value of what they may gain by giving that up. – James Belasco and Ralph Stayer.
The Change
It might seem like Converting the team to adopt TDD is never going to happen… It can, but change takes time. Certain prerequisites need to be fulfilled to make it to the finish line.
The proverbial first step would be to cleanse yourself of all sin! Get the team to start writing CLEAN CODE. It might seem like it’s a rudimentary part of the development process. But still, a majority of developers don’t focus on writing clean code. With clean code, we must focus on the code to be testable. Initially, this is going to be difficult but getting the team to make code testable would be a major milestone. In the JavaScript ecosystem, a linting tool will be a good place to start from a source code management point of view.
The Focus Should be on writing good test cases first instead of prioritizing on the CI/CD aspects or the automation aspects of the application design. Most team leads try to focus on getting a 100% score on their code coverage. A 100% score does not warrant that the test cases have covered all the possible positive and negative unit test scenarios.
Familiarizing the team with the testing framework that is going to be used. Almost all testing frameworks have the same core concepts of:
- Assertions
- Expects (expectations)
- “describe” and “it” keywords.
Getting the team to be well versed in the testing frameworks helps in honing the skills of the developer to think more on the lines of automating test cases.
When transforming the development team to start TDD it would be wise to start with pair programming. When developers work in pairs it adds to new perspectives into how to write quality tests. One approach to getting your team to practice TDD more efficiently is to covert/train one developer at a time. Yes, it will be time-consuming. Yes, it would stretch the timeline of switching completely to TDD. You could speed the process up like a chain reaction but you will have to start with a handful of developers first. You would have to ‘indoctrinate’ the developers one at a time. the virtue Patient is key!
Comments
Post a Comment