Imagine a company with two large development teams.
Both teams work on the same product under the same scarce resources.
Features have to be developed and wide landscapes in the code have to be changed a lot.
For organisational reasons, the forks are only merged sporadically.
Team A develops responsibly and professionally but without much attention to testing. Time is short and the product owner wants to see results, stable or even beautiful code is secondary. Core features are covered by unit tests, everything else is manually approved by at least two instances.
Team B follows the principle of TDD. Not just a handful of unit tests, but the complete program: Integration, smoke and snapshot tests, high test coverage, you name it.
After months of development comes the time when both teams have to merge their work. Team B now has a decisive advantage: even before the product saw the light of day, the build process reported that something was amiss.
Detecting, identifying and fixing the errors is a painstaking task that can be solved with relatively little manpower. With Team A the whole thing looks different.
Do the features still work? You can only find out if someone takes the time to test the program manually. If not, where is the error in the code? Only the developer who implemented the feature can say. In the best case, the developer in question has overlooked a little something, in the worst case it is a regression due to the merge.
Even though Team B had to put in more effort during the development, it was worth it for the team and especially for the company.
But TDD also has many more advantages, which are not only to be found in merging and refactoring. At this point I would recommend Clean Code to every developer, young and old alike. Because TDD is not only about test coverage, but also about HOW to write code. Your colleagues will thank you for that.
Have fun. Enjoy coding.
Your INNO-coding team.