First, many job postings ask for TDD. Most companies want people who know it, but they will NOT do it. So knowing and speaking intelligently is going to cover a huge amount of job postings. It is often sought because some of the most well-known people in our field use it and have written about it extensively. It is also one of those things that are labeled a, "Best practice."
Second, TDD is a skill. It takes dedication and practice just like any skill. I've been doing TDD near exclusively for about 5 years now.
The benefits that I have seen come with it are:
High-confidence in production
Fewer defects and bugs related to my code
Very few "Your code is shit" conversations
My code becomes very obvious
My tests tell me what the code should and shouldn't do months from now
My code begins to take on more traits of well-designed code
I become very familiar with the tech through failing tests
I'd like to separate out two things.
First, many job postings ask for TDD. Most companies want people who know it, but they will NOT do it. So knowing and speaking intelligently is going to cover a huge amount of job postings. It is often sought because some of the most well-known people in our field use it and have written about it extensively. It is also one of those things that are labeled a, "Best practice."
Second, TDD is a skill. It takes dedication and practice just like any skill. I've been doing TDD near exclusively for about 5 years now.
The benefits that I have seen come with it are:
I wrote an article here about trying TDD out