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.

You may think your design is loosely coupled and well usable. You may even be right, if you’re really, really good at designing. The trouble is, many people think they’re great designers, and some of them, in fact, aren’t. TDD forces you to prove that the design has the properties you think it has, much like testing in general forces you to prove (approximately, not formally) that the code is correct, rather than just assuming it is correct.

About refactoring: You could add unit tests if and when you refactor, and in fact that is precisely what is suggested for working with legacy code. However, once you are at the point where you have to refactor a big mess of code, you almost certainly have forgotten details, edge cases, semantic nuances of certain values etc. etc. that should have been properly documented, but weren’t. Again, existing unit tests will already capture this detail knowledge, which is why writing them early is better than writing them late. A test written immediately before refactoring is much less likely to actually test what it should test.

Point three seems to be a mixture of other points and some things I don’t really get, so: I don’t know.

Point four: I don’t believe it’s possible to have a bias towards “typical bugs” that aren’t detectable by tests. What would those be? Sure, there are issues that are much harder to test than other issues, such as problems that can only occur in extreme integration situations (e.g. going live with millions of users simultaneously), but would anyone really have a knack for writing correct code except in such situations? Seems unlikely to me.

Changes in staff are definitely a big issue – the bigger the organisation, the bigger an issue it becomes, but even if you program alone, the person who looks at the code a year from now and wonders “what idiot programmed that??” is very different from the one who actually wrote it – even if they are technically the same person. This happens to me all the time. A unit test gives you a chance to understand why and in what way the system doesn’t quite work the way you thought it did.

Overall, then, the really important point (to me) is to write the tests while you still understand the system fully and with as close to 100% coverage as possible. Whether or not you actually write each test a minute before you write a routine or a minute after is actually slightly less important.

Let’s address different point first: what do you understand by “simple unit test”? You’ll write one test for happy-path only? Only methods you think might break? It’s difficult to tell what you have on mind, but for the remainder of this post I’ll assume you’ll write only some tests where you consider them useful, instead of doing close-to-full coverage like TDD would result in.

Few notes to your points:

• TDD makes you define the interface first: that’s not really an argument for TDD, as you can define interface first without it. What TDD does instead, is make you focus on high-level details of piece you’re working on at the given moment, without being disturbed diving deep into dependencies. But then again, this is not TDD specific.
• TDD requires more time even considering debugging benefits: this is true, simply because in TDD you write more code. Indirect advantage is, that due to the fact you’ll have much better coverage than “sporadic unit test” approach, regression will be less painful.
• “if my typical bugs are not approachable by predictable tests (…)”: is it really a bug when you know about it upfront and write code to prevent it before it actually happens?

I think you’re comparing wrong approaches. TDD vs “sporadic unit testing”, while it should be full testing vs sporadic testing. TDD will result in full testing, but you can achieve that without TDD just as well.

You need to decide how valuable you consider decent code coverage (not the delusive magical-fairy-tale 100%) vs “some” coverage; weight time spent on writing extra test code vs time gained when tests actually help you discover and fix regression related bugs, as this will be their main advantage over no-tests approaches.

An important thing I’ve learned last week regarding TDD is that it is something different than writing your tests first only. The main advantage of TDD as a design principle is that it makes you think about what you need when you need it (the YAGNI principle).

Interesting reads:

• Microsoft Takes it on the Chin Over Test-Driven Development (Scott
  Bellware)
• The various meanings of TDD (Roy Osherove)
• Does Test-Driven Development Really Improve Software Design Quality? (David S. Janzen, Hossein Saiedian)
• Red-Green-Refactor (James Shore)

First i started creating Unit tests for where i thought it’s necessary. To make it worse mostly i’ve done it after i wrote the code to be tested.

The fact that i could choose what to test i could (i’m not a strong person you can say) leave out important/risky code parts because i said: yeah that’s never gonna broke.

The fact that i wrote the tests after the code made my code hard to test. It was not unit based but instead a collection of hacks (which can simply be because i’m not talented).

Once i’ve started TDD

• I could never leave out stuff (or a lot less likely) from testing
• I wrote only the code that was really needed
• My code was well (or at least better) structured.

Happy coding!

I often write unit tests but I think that, as any tool, they are not the solution for all problems and one should evaluate from case to case whether they are appropriate or not. Using them systematically for every piece of code I write does not seem the most effective solution to me.

Here are some situations in which unit tests have proved to be very useful for me:

• Validating methods that perform complex data transformations: unit testing with a lot of possible inputs and outputs allowed me to discover even small bugs very early.
• Refactoring: unit tests help to ensure that the refactored code has the same functionality as the original code. Newly introduced bugs show up very soon.

On the other hand, I have some doubts regarding TDD and whether this approach is always the best. Here are some points of criticism:

Not all the code can profit from unit tests, e.g. suppose that you want to check that a certain event is dispatched to the correct component in your GUI. The most effective thing to do is to run the program and, say, check that the appropriate button is enabled. The effort needed to unit test the underlying logic would be too high compared to the manual tests that (at least if you have a decent development process) you are going to carry out anyway.

I sometimes develop interrelated classes as clusters and I am not sure which classes and methods I really need until the whole cluster of classes is finished. Such a cycle can last a few days. During such a cycle I can introduce new classes and then, on a second thought, realize that I do not need them and remove them. If I had written unit tests for these classes, I would have had to throw away the unit tests as well. So I find it much more efficient to (1) write unit tests for selected, critical classes and (2) start writing the unit tests towards the end of a development cycle (of a few days) when the class structure has stabilized enough, so that I do not waste my time writing unit tests that I am going to throw away later.