&quot;How would you distinguish automated testing from TDD?&quot;<p>I would consider the distinguishing characteristic of TDD is that you write the tests first. There&#x27;s varying levels of strictness there from little more than that restriction, to varying levels of dogmatism on writing code that <i>only</i> makes the test pass.<p>I consider this a great way for a new programmer to learn how to really <i>design</i> code. In fact it&#x27;s one of the only ways I know to practically teach design. However, once you have experience, the really dogmatic TDD involves writing simple tests, then writing code to pass the tests that you, in your experience, <i>know</i> will be driving yourself into a local optima that will not be able to carry the design. But when you lack that experience and knowledge, well, it&#x27;s a great way to get it while learning a good dose of YAGNI. (Which I do not consider an absolute, but is something everybody needs to exercise.)<p>In contrast to &quot;TDD&quot; which I consider optional, automated testing has provided so much value to me in so many diverse parts of the stack that I consider it a no-brainer; it is a positive value to any project. The exceptions are things where the code is <i>so</i> not-amenable to testing that it is essentially untestable. Note this <i>only</i> applies to code written by <i>someone else</i>; if you wrote it, fix it to be testable. In particular, GUIs are a <i>royal</i> pain here. It is my belief this is not a fundamental attribute of GUIs, but a GUI not written to be testable is nigh untestable.<p>(And if you find it isn&#x27;t bringing you value, you&#x27;re probably doing it wrong. There are wrong ways to do it. Test code is real code; apply all the arts of refactoring, DRY, and learning from experience as you do to &quot;real&quot; code.)