I think you are making a false dichotomy. I am very, very pro TDD and very, very against mocking.

The problem is that certain architectures are very hard to test without resorting to either mocking or integration tests. In those cases you have to weigh which is better, writing painful integration tests (or not having test coverage at all) or changing the architecture, or in certain exceedingly rare cases mocking.

Possibly, but I also think I am accurately summing up DHH's article http://david.heinemeierhansson.com/2014/tdd-is-dead-long-liv... and UncleBobMartin's reply where both talk about TDD mocked tests passing in seconds.

I guess mocking or not mocking was not my take from either of their articles. I thought they were both about test scope. Mocking is one way of limiting test scope but there are others.

I'm ok with different readings of the articles as long as TDD doesn't start automatically being associated with mocking.

You'll have an uphill struggle if you want to stop TDD being mocked ;)

Well played.

The linked article does not support your assertion. It speaks to being careful not to overuse mocks, but does not state that mocks are inherently distrustful. If anything, it implies the opposite since it is saying "here are some things to avoid when using mocks", which implies the usage of mocks in the first place.

The reason I like TDD is that the feedback I get from it is very close to what I'm working on at the time, which I believe shortens overall development time.

As part of TDD, mocking is valuable because it allows one to handwave around parts of the system you don't care about at that moment. "Assuming this other method I rely on works..." can save a lot of time in setup and, again, tightens up the feedback loop.

For what it's worth, I think both isolated tests and system tests have value, and I do both of them. I think relying on only one style is limiting and shortsighted.

The problem is that TDD only works in a subset of problems and programming languages, but it gets sold as the ultimate solution.

I am yet to see usable TDD approaches for strong typed languages in projects with dependencies to third party binaries, specially if those binaries are native code.

No proper way to design and test UIs, complex algorithms and data structures with TDD.

I'm not sure I understand. I've written thousands of tests over the years in strongly typed languages, with third party dependencies. Further, I've written complex algorithms and data structures with TDD (in fact that tends to be when it is most useful).

UIs are more complex to TDD that is true, but at the very least I've found that because UIs are hard to test, TDD drives you to put the least amount of logic in the UI layer, which is a very good thing.

I've still haven't found a satisfactory way of doing TDD with UIs. Being able to do MVVM with WPF got pretty close but it felt a lot more like driving the application with selenium or something akin to it. iOS seems worse, but I've only dabbled in it.

> I'm not sure I understand. I've written thousands of tests over the years in strongly typed languages, with third party dependencies.

Usually there is no way to mock that DB connection happening two layers down in the compiled code inside the .dll/.so/.a/.lib.

With a dynamic language you just monkey patch it, after some debugger introspection.

> Further, I've written complex algorithms and data structures with TDD (in fact that tends to be when it is most useful).

How did you design cache friendliness, memory layout optimizations, O() access times, with a "write test, fail, write code, success" approach?

> UIs are more complex to TDD that is true

Yes, and most important TDD fails at the UI design part, specially on native UIs.

The use of a third party black box with side effects in your architecture is going to have obvious and difficult impacts on the design of your system. In order to minimize this impact you will need to isolate that code dependency from other parts of the system. There are many ways to accomplish this isolation, dependency injection is the most obvious one and easy dependency injection is one benefit of some dynamic languages. That isolation is not a result of TDD, it is a good design principle that TDD helps enforce.

As for cache cohesion, algorithmic complexity, etc. I wouldn't encode those in a test any more than I would encode a requirement to use while loops vs. recursion. I've never encountered a specification that cares about those things, rather typically you care about some performance metric, median latency, worst case latency, sustained throughput, memory usage, cpu utilization, etc. If those things are important enough to be specified, they are important enough to be automatically tested. Writing performance correctness tests first has all the same advantages as writing algorithmic correctness tests first, and I heartily recommend doing so. If I ever encountered a specification that actively cared about memory layout, I would first be suspicious of the requirement but if it turned out to be real I would spend a lot of time figuring out how to test it.

I fully TDD all aspects of web UI's -- what parts do you find difficult?

How do you TDD CSS and dynamic transitions on the UI, according to the target browser layout, in all devices request by customers?

For example, TDD a CSS responsive transition among Chrome, Safari, IE, iOS, Android, WP, TV settop boxes across multiple resolutions.

I usually just test the addition/subtraction of a class, and don't test the purely visual elements.

So you just contradict yourself? So you don't really test all aspects of web UI's.

I suppose you're correct. We are starting to do some image-diff based regression testing, but I'm not sure that anyone really does css TDD.

TDD is in large part about getting the feedback-loop cycle as quick as possible while you're developing. JS unit and integration testing can help with the functional aspects, but visual aspects are better paired with a tool like livereload.

I use test doubles (mocks, fakes, stubs, whatever) and I still distrust them. Test doubles let you run your core logic quickly against your collaborators based on assumptions about how they behave.

You also need integration tests to validate that those assumptions aren't wrong. It's not either/or, it's both, mindfully applied.