I've read some basics about unit tests and TDD, but I find it hard to convince myself why TDD can have an advantage over only selected unittests.I've read common arguments for TDD, but don't see the improvment compared to simple unittests. Maybe you can help to clarify:TDD allows a loosely coupled, testable design -> I believe I can well imagine if a class is theoretically testable, without having to write tests; Loose coupling is a fundamental requirement that one can judge without refering to TDD?!TDD gives confidence in refactoring -> Isn't it more efficient to add selected unittests as soon as you start refactoring? While you have to think what to cover by test, you still save writing a lot of tests.TDD makes you define the interface first -> To me it seems some minor points are easier to decide while coding (which also agrees with agile?). It's even hard to predict a nested return data structure, but after coding I can often validate that I get what I expected. I made up the nested data while coding (a small unit) and see the behaviour. I'd save a lot of time writing the method first and using the validated result a posteriori to plug into a unittest.from what I've read many (of course not all) sources state that TDD does require more development time even considering the benefit for debugging; merely the code quality improves -> Can it be that some programmers make different kinds of mistakes and for some TDD doesn't cover the type of mistakes they make anyway? So if my typical bugs are not approachable by predictable tests, it's not for me?TDD aids changing teams, and larger interacting teams -> Is this a large issue? I can imagine it is, however as for the moment I program alone I cannot judge. How does TDD help teams in ways that... and here is the important point: other ways don't? It can force some discipline for less experienced team members, but apart from that any advantages?
Sporadic unittests or TDD?
unit testing;tdd
TDD allows a loosely coupled, testable design -> I believe I can  well imagine if a class is theoretically testable, without having to  write tests; Loose coupling is a fundamental requirement that one can  judge without refering to TDD?!You are right TDD helps you learn how to design this way, by forcing you to.  But riding a bike with training wheels isn't always necessary, it's possible to design well without TDD.TDD gives confidence in refactoring Isn't it more efficient to add  selected unittests as soon as you start refactoring? While you have to  think what to cover by test, you still save writing a lot of  tests.The problem is you may not remember what unit tests to add when you revisit the code days or months later.  You may need to refactor just to add unit tests, breaking things unexpectedly.  At the same time, unit tests may need to be refactored as well, increasing the overhead.  Or unit tests may give you false confidence.  It is very situational whether or not test-first or test-after is more effective.TDD makes you define the interface first - To me it seems some minor  points are easier to decide while coding (which also agrees with  agile?). It's even hard to predict a nested return data structure, but  after coding I can often validate that I get what I expected. I made  up the nested data while coding (a small unit) and see the behaviour.  I'd save a lot of time writing the method first and using the  validated result a posteriori to plug into a unittest.Thinking test-first takes practice, but has the advantage of ensuring your code is unit-testable without refactoring.  BTW don't write an Interface first if that's what you are thinking, you write a interface first (all classes have interfaces).From what I've read many (of course not all) sources state that TDD  does require more development time even considering the benefit for  debugging; merely the code quality improves -> Can it be that some  programmers make different kinds of mistakes and for some TDD doesn't  cover the type of mistakes they make anyway? So if my typical bugs are  not approachable by predictable tests, it's not for me?TDD can take far less time than normal, but you need to practice it enough and learn what tests are most effective.  Do pure TDD on a pet project to see what it's like, but don't do pure TDD everywhere - it's a waste of time.  Instead apply your TDD skill selectively (mix of hand/unit/integration tests some test-first some after), again this requires experience.TDD aids changing teams, and larger interacting teams - Is this a  large issue? I can imagine it is, however as for the moment I program  alone I cannot judge. How does TDD help teams in ways that... and here  is the important point: other ways don't? It can force some discipline  for less experienced team members, but apart from that any advantages?TDD takes a long time to learn and will send a project into a nosedive if you apply it to a team that doesn't know it at all.