Why aren't developers practicing TDD?

Maybe I'm just not talking to the right developers, but it seems like no one practices test driven development (TDD). I was first introduced to the concept around 2010 (it's been around even longer) and I thought "wow" this is a great idea. In case you are not familiar with TDD, the general idea is for developers to write unit test code before writing the actual code. The unit test will fail, then the developer will write some code to make the test pass. In the end if following this rigorously the theory is that all production code should have a corresponding unit test. Just in case you're not familiar with unit tests, these are tests that are run automatically to help improve code quality and avoid creating bugs in software.

Over the years since then I've worked on many projects under many different roles and generally the test coverage is minimal, and I've rarely met a developer who worked on a project where TDD was in practice. I do a lot of technical screenings for developers and generally when discussing TDD, most will tell me they know about it in and think it's a good idea but have never actually done it in a project. There are several reasons for this but I think the story I've heard the most goes something like this:

We tried doing unit tests but it takes too long and we have pressure from our management to deliver faster, so the tests are not considered important

There are a plethora of other reasons I've observed that account for this lack of testing but generally it comes down to the time thing. I know of one partner that actually quoted a project with tests and without tests, and of course "with tests" cost 25% more. To me this is just wrong. If done properly it should actually cost less money with tests. As I see it the problem is generally a misunderstanding at the management level as seeing the testing as too time consuming. While it is true that developing the test case requires writing more code than just developing some code, I disagree with the misconception that it is more time consuming. As a developer, at some point while writing code you'll want to test it. If we're considering a web application this typically involves starting up a server and then maybe clicking through a web interface for some time in order to arrive at whatever feature you are developing. Maybe you have a debugger connected and will start stepping through your code and miss something, then you want to test it again, so this means you have to re-click through your web interface to get back to whatever state you were in to see what's going on. Now let's see how this happens with the TDD approach. Your test case is ready to run whatever code you are developing, so when it's time to test, you run the test case, and that's it. I should point out that there are better ways to test your code than using a debugger but this is just an example. To summarize there is an upfront effort to write some additional code but in the long run it saves you time. There are many other benefits to TDD, mainly improved code quality. As systems get more complex, testers have more things to test and are more likely to skip some less common cases. Having unit tests covers you in these cases.

To follow up on this previous example, in some real projects I've worked on, the upfront cost is often high. However it should not be - most of the time it is developer inexperience in writing unit tests. One common pattern I've seen, a project will start out with the intention to do unit tests. Developers struggle at the beginning and progress is slow. At this point either a project manager will complain that things are moving too slow and developers will give up on the testing to speed up, or project managers are patient and developers ramp up on test writing skills and after 2 or 3 sprints progress is going much faster.

As an industry I feel we really need to communicate the benefits of TDD over the initial cost. I'm not suggesting that TDD must be followed 100% of the time. There are many cases where it can be overkill, but it should definitely be more common. This applies to developers but I think it is even more important to communicate with managers about this topic.