Apparently they aren't willing to hack the language interpreter a little to improve their testing? py.test does some cleverness to reinterpret assert statements and capture subexpressions, and in the process solves the problem that a whole series of assertEqual/etc methods are created to solve. Doctest solves it in a slightly different way, by basically turning everything into assertEqual (though the fact that is less general can be a problem).
RSpec is doing something else besides this, I think. The tutorial isn't completely up-to-date, so now you can actually do x.should.be.foo which I think is entirely equivalent to assert x.foo?. Since these transformations are generally pretty easy and obvious (and they are supposed to be easy and obvious), I'm not sure what the advantage of the RSpec style is. Maybe if I saw his presentation.
I do think it is or can be correct that "Behavior Driven Programming" is different than just "Test Driven" or unit testing. There really is something different to starting with doctest than with starting with unittest or py.test. It's closer to acceptance testing; acceptance testing of the API, I guess. Unit testing tends to be more focused on testing the internals. By emphasizing a story, doctest is encouraging you to talk about what things look like from the outside. I expect that the style RSpec is implementing is intended to do the same. But creating a DSL for that seems like exactly the wrong thing, because you aren't describing something that anyone can use. When talking about an API, you should be using the API, nothing more.
Ahh, true - I tend to write my tests as "this is how the API should work", so maybe I'm just an early adopter of "Behavior Driven Testing"? :) Although, I thought I was just doing good Test Driven Development... but my point is, TDD freaks people out almost as much as Pair Programming, so if someone wants to try a new name, I'm ok with that.
After watching the Google TechTalk video ( http://video.google.com/videoplay?docid=8135690990081075324&pl=true ) on this I think something like this would be a nice thing in Python. Sure it's really just TDD, but it's changing the semantics to encourage good TDD practices instead of just a verification mechanism.# Steve