There's a big swath of time between the rise of the xUnits and the modern Mock fancy he doesn't cover (or provide citations for).
Considering the early TDD mantra was red-green-refactor, saying you could do it with all Acceptance tests is a bit of a stretch. I mean tomato tomatoe I guess, but that's certainly not a definition I've ever come across (and it would certainly run afoul of Uncle Bob's 3 rules of TDD).
Try looking for how many times "design" is mentioned on the page, and in what context. That's how TDD was sold to me. Is your component difficult to test in isolation? Then the design is flawed. One of the big advantages of TDD early on (and it seems to hold true today) is that it helps you write testable code (in Units).
BTW, I didn't suggest XP and TDD were the same. XP2000 was a conference. You can believe me or not I guess, but back in the day all you had was your xUnit. Selenium was a twinkle in someone's eye and local databases were not the norm. It was definitely all about the Units (and I think if you read the material of the time the emphasis will be pretty obvious).
TDD and XP are not the same thing, either. I don't have my copy of "Test-Driven Development by Example" handy, so I'll just have to point you to http://en.wikipedia.org/wiki/Test-driven_development , which doesn't use unit tests in its definition.
Now, it's not that there's no connection at all: unit tests are _incredibly_ helpful when doing TDD, because you want your tests to run quickly. But it's "Test-first," not "Unit-test first." When you're doing TDD, you don't write acceptance tests second, you write both your acceptance and unit tests first.
> "The classical definition of a unit test in TDD lore is one that doesn't touch the database."
So nope. Not confused. ;-)
That said the conference he referred to happened in 2000 (http://martinfowler.com/articles/xp2000.html) and his claim is that Mocks didn't take hold until long after.
There's a big swath of time between the rise of the xUnits and the modern Mock fancy he doesn't cover (or provide citations for).
Considering the early TDD mantra was red-green-refactor, saying you could do it with all Acceptance tests is a bit of a stretch. I mean tomato tomatoe I guess, but that's certainly not a definition I've ever come across (and it would certainly run afoul of Uncle Bob's 3 rules of TDD).
edit: BTW, c2 has a wealth of information on the subject: http://c2.com/cgi/wiki?TestDrivenDevelopment
Try looking for how many times "design" is mentioned on the page, and in what context. That's how TDD was sold to me. Is your component difficult to test in isolation? Then the design is flawed. One of the big advantages of TDD early on (and it seems to hold true today) is that it helps you write testable code (in Units).
BTW, I didn't suggest XP and TDD were the same. XP2000 was a conference. You can believe me or not I guess, but back in the day all you had was your xUnit. Selenium was a twinkle in someone's eye and local databases were not the norm. It was definitely all about the Units (and I think if you read the material of the time the emphasis will be pretty obvious).
You might also consider that http://en.wikipedia.org/wiki/Test-driven_development#xUnit_f... pretty strongly associates TDD with Unit Testing.