I think a lot of distinct, but interrelated topics are being brought up here: * Using tests as a (or even the primary) design tool (strong TDD) * Test-first d

I think a lot of distinct, but interrelated topics are being brought up here: * Using tests as a (or even the primary) design tool (strong TDD) * Test-first development (weak TDD) * Integration vs. unit testing * What is a unit test? * Should one use mocks and if so, when and how? I think each of these topics merits a separate discussion and you can be e.g. in favour of at least weak TDD while maintaining that unit tests have little value, or you can be in favour of unit tests but disagree that "unit test" means "unit = class/method/function". You can have differing opinions on the value of mocks even if you subscribe to strong TDD (that's essentially the classicist vs. mockist divide in the TDD scene - for example, Bob Martin is more skeptical of mocking than, say, the "Growing Object-Oriented Software, Guided by Tests" crowd is). IMHO, the biggest problem with testing is that most developers are not very good at it. I routinely see tests that are so complicated that it becomes very hard to understand, let alone debug them. In my experience, a lot of people also skip tests when reviewing code. Well-written tests make a code base a joy to work with. Bad tests make everything painful. I don't know how to fix this, but we should pay more attention to it. If we had better tests, it would be easier to argue about the merits of TDD, unit testing, mocking etc. With badly written tests, everything devolves into a "why even test [this specific thing]?" kind of discussion.