Huh. "Behavior Driven"? Hey, I hear those Ruby people are good at marketing, so maybe they needed a new name for unittesting? Maybe that's not a bad thing. RSpec seems like .. exactly .. py.test? I can't find the blog article mentioned (A New Look at Test Driven Development), but is there some aversion to "assert" in tests that I'm not aware of? Doctest is even nicer, when that's all you need, but other than the Ruby habit of using words to mean builtin things (DSL, righto) x.should_equal 0 => assert x == 0, right? I thought there must be something more I was missing, but here's the full list of expectations that I can find in the source doc on the RSpec site:
should_raise -> assert py.test.raises should_not_raise -> assert not py.test.raises should_be_empty -> assert len(x) == 0 # couple options here, depending on what this means should_be_false -> assert x is False should_be_nil -> assert x is None should_be_same_as -> assert x is y should_be_true -> assert x is True should_equal -> assert x == y should_include -> assert x in y should_match -> (not sure what this ruby means)
and _not_ versions of the same.
Clearly, the whole point of this is a test assertion DSL? Agree with you that creating this by putting methods onto Object feels much less acceptable to my non-ruby/smalltalk mind. But ok, maybe someday I'll go the rest of the way in this DSL fervor.
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.# Ian Bicking
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