Writing code using automated testing is the most important thing you can do to set yourself up for success. Look, we've heard all of the arguments about TDD and automated testing before:
But if we had to pick absolutely one reason why you should be testing your code it is this one:
Code written with a safety net, over time, allows itself become better code. When you write code without this safety net, you're always afraid of making changes. The code gets worse over time.
This phenomenon, known as cyclomatic complexity, is well understood by developers but poorly understood by non-coding techies.
The problem is most early-career developers don't know this or don't work in environments that support strong agile and automated testing principles.
Sadly, the significant Pareto principle now affecting the tech industry has artificially created a generation gap: Most young people today no longer associate "agile" and "lean" with meaning automated testing and tested codebases. But this is a lie, because you can't be seriously building agile software without automated testing.
It's just simply not possible to do. The dirty little secret is that the successful techies never bothered to turn around and tell the rest of the pyramid.
At Helios, we practice what we preach and have put our money where our mouth is. We only take on clients who are committed to quality, tested codebases.
Studies involving engineering teams at Microsoft and IBM concluded that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Specifically, the IBM teams reported a drop of 40% in defect density, and those at Microsoft reported a 60-90% drop.
Based on the results of a study presented from 2007, Maria Siniaalto and Pekka Abrahamsson report that TDD has been shown to produce better code quality when compared to non-TTD developed software. Siniaalto and Abrahamsson cite a study conducted in China that concluded that TDD improved process tracking and task estimation. The same study concludes that TDD makes everything consistent. This results in better quality with fewer defects. Also, the teams that used TDD were better able to fix their defects more rapidly. link
Boby George and Laurie Williams, both working in the Department of Computer Science at North Carolina State University, ran an experiment where 24 programmers were put into two groups: one used TDD and the other the linear approach. link George and Williams report that out of the participants, "92% of developers believed that TDD yields higher quality code, 79% thought that TDD promotes simpler design and 71% thought the approach was noticeably effective" link