> One of my biggest issues with "pure" TDD, is the requirement to have a very well-developed upfront spec; which is actually a good thing.

Can you expand on what you mean by "a very well-developed upfront spec"? Because that doesn't sound at all like TDD as i know it.

I work on software that takes in prices for financial instruments and does calcualtions with them. initially there was one input price for everything. A while ago, a requirement came up to take in price quotes from multiple authorities, create a consensus, and use that. I had a chat with some expert colleagues about how we could do that, so i had a rough idea of what we needed. Nothing written down.

I created an empty PriceQuoteCombiner class. Then an empty PriceQuoteCombinerTest class. Then i thought, "well, what is the first thing it needs to do?". And decided "if we get a price from one authority, we should just use that". So i wrote a test that expressed that. Then made it pass. Then thought "well, what is the next thing it should do?". And so on and so forth. And today, it has tests for one authority, multiple authorities, no authorities, multiple authorities but then one sends bad data, multiple authorities and one has a suspicious jump in its price which might be correct, might not, and many more cases.

The only point at which i had anything resembling a well-developed upfront spec was when i had written a test, and that was only an upfront spec for the 1-100 lines of implementation code i was about to write.

So your mention of "a very well-developed upfront spec" makes me wonder if you weren't actually doing TDD.

No argument about testing user interfaces, though. There is no really good solution to that, as far as i know.

You still had an “upfront” spec. You just didn’t write it down, and applied it in a linear fashion. I assume that you are quite experienced and good, so it was a good way to do things.

I tend to be highly iterative at the design, and even requirements level, in my work. Not for the faint of heart. I often toss out tons of code. I literally have no idea how something will work, until I’ve beat on implementation (not prototype) code, rewritten it a couple of times, and maybe refactored it in-place. Then, I refine it.

I seldom write down a thing (concrete galoshes). If I do, it’s a napkin sketch that can be binned after a short time, because it no longer resembles reality.

I’m a big believer in integration testing, as early as possible. The way I do things, makes that happen.

It’s the way I work. But an important factor, is that I tend to work alone. My scope is, by necessity, constrained, but I get more done, on my own, than many teams get done, and a lot faster, higher-Quality, and better-documented. I also write the kind of software that benefits from, and affords, my development style. If I was writing engine code, my way would be considered quite reckless (but maybe not that reckless. I used my “evolutionary design” process on my BAOBAB server -which I outline in [0], above, and that server has been the engine for the app I’ve been refining for the last couple of years. The process works great. It’s just a lot more pedantic and disciplined).

If I work on a team, then the rules are different. I believe in whitebox interface, and blackbox implementation. That’s a great place to have TDD.

> makes me wonder if you weren't actually doing TDD.

I get that kind of thing a lot. I fail most litmus tests. It’s a thing…

Lots of folks here, would defecate masonry at the way I work.

I don’t have to please anyone during the process. They just see the end result; which is generally stellar.

Since one thing that geeks love to do, is sneer at other geeks, I am sort of doing a public service. No need to thank me. The work is its own reward.