The TDD Hoax
If you are a software developer then you should haved heard about the term Test Driven Development(TDD). But given the fact it is widely adopted, the outcome of the team following TDD can make you think is it really worth it.
Before diving into conclusion. Lest see the main reasons why TDD fail in many development teams
You donot write test first
The main advantage of writing test first is that it helps to analyze the problem before solving it. Developers often tend to think about terms like database, queues and services. But we should always remember that we are there to solve business problem. Analyzing the business problem and modeling it properly in your code is the frist priority than directly jumping into database.
This also helps engineering team to work directly with product owners and figureout pitfalls early than regretting at the end.
Your test is direcly dependant to the system dependencies
This is a huge one. The test you write should not be dependant to the system dependencies. By system dependencies I mean like database, queues, HTTP status code, api calls etc…
Here is one example of such bad test
1. test.ExpectInt(t, res.HTTPStatus, 500) 1. test.ExpectAPICallWithURL("https://blahblahblah.com")
Your test should barely know the api call or http status code or database. All it needs to know is if it fulfills the business requirement. As we make test more dependent to these terms - our tests fail frequently with code base changes. This ultimately results to slow and underperforming teams.
You write test for PR approval
May be I dont need to explain this.
Your test fail frequenly even with small product changes
One major reason we follow agile is that - we know business requirement and changes are never ending process and we need a process that helps us adapt these changes by reiterating these ideas and reviewing valuable user feedback. If your code cannot match the pace with these changes because the test you have written fail frequently then the team is bound to under perform.
Let’s say we have an application to fetch wether data which fetch weather info via an api call from website
https://blahblahblah.com. Now if your business deciced that it no longer needs the api vendor, then you test will fail if you have following code anywhere in the test.
Then how do you approach this problem?
You should test the business needs not the system needs. Even though your vendor change you always need a source for the data. So you mock the behaviour and test the outcome.
You dont know the business need
If you dont know what values the feature is adding to the business then friend that task is similar to doing manual labor in a hot sunny day on a daily wage basis. Your work will never be valued. Its time to pack your bag and leave the shitty place.
Enough with the failures…
Adapting a process is one thing. But having all team members convinced about the process is other thing. I have seen development teams follow a process just because a fancy tech giant follows it. It is an utmost important that all team members acknowledge the values that a well defined process is bringing into the team than just announcing -
OKAY! we are following this from now onwards! Get prepared !!!
Benifits of TDD
Now its time we acknowledge what TDD bring to your team
It bring product owners and engineering team closer
As mentioned above TDD helps to well defined business problem prior to development. This can raise many valuable discussion on product development cycle than getting a shitty email about product release date extension. This will create a more agile team where PO come closer to the engineering teams to figureout more optimal ways to solve the business problem
It makes your code clean
This can be ambiguious but a code which is open for modicafication, ready for adapting changes, and designed with mindset of business requirement first, definetly has clean code that the overengineered, heavily modified, tightly coupled, and desinged with no business understanding at all.
Increase product confidence
No need to explain at all.
You know product requrement change. You know there will be feedback. You know there will be reiteration. You adapt to these changes.
You are agile!
We follow process and blame it for our failures. It is always necessary that the development teams see a process as a valuable asset to the team than just a way to bound people to work.
Happy New year 2078!!