Well of course I am trying to prove a point to you! Smile (just as you are to the universe! Smile) So yo, let me get all up in your face about BDD... Wink
<looks for dark corner to hide in...fails>
- "TDD is not, will not, and never has been, a testing methodology." This is nice spin, but it is simply not true. It is both a design and testing methodology -- which is the beauty of it.
I disagree. It's entirely true. That it gives rise to test coverage is inevitable, but not the core goal. TDD does not test code, since such code does not yet exist. I was pointed to the following quote recently from Jimmy Nilsson:
"One way to describe TDD is to say that you use tests or examples for specifying behaviour."
Applying Domain-Driven Design and Patterns, was published in 2006. If you're not specifying, then you must be verifying. Verification is not a part of TDD.
- "In TDD, which utilises Unit Testing, we usually end up testing on a per unit basis." Actually you build on a behavior-by-behavior basis and end up organizing in units. Maybe the syntax sucks, but that's what happens.
And it's not entirely right. How does behaviour give a crap how many classes/methods you have? If three classes cooperate to give rise to one required behaviour, then does this mean you must test all three classes, or all three as a singular system? What if the three classes were the result of refactoring from a single class already covered - does this suggest we start expanding the specifications, or the tests, to create new class specific testing code? So no, such organisation of tests and production code is a testing approach, not a part of TDD. TDD already gave us a safety net before we refactored - the safety net never changes unless the behaviour does. So any extra code thereafter is for testing only, and unrelated to TDD.
Not sure I explained that brilliantly well - the point is that behaviour and units are rarely a simple 1:1 map.
- Your three rules are to stop using the words "test", "unit" and "assert". Hence my comment above about syntax vs substance. And for the record I think using different words can be useful.
Define substance? If BDD can help improve people's understanding and adoption of TDD's goals then is this not of value? Then there's the integration of DDD and ATDD. The language changes have more consequences than you're considering.
You really don't have to vilify TDD to promote BDD. I think that is your big mistake. Anyone who has embraced TDD understands the potential benefits of BDD, so why antagonize. Anyone who isn't using tests will have to use them in other areas even if they use BDD, so why send a negative message about testing.
Now, now. The entrance sign clearly states that Straw Men are barred from these proceedings

. I have never vilified TDD (least not intentionally - see JCarts concerns earlier that had me worried). I have never criticised testing either. I have only noted that explaining TDD in terms of testing is not a good idea. Since TDD is not a testing methodology.
If you focus too much on the fluent interfaces and natural language strings -- you end up with the smurf discussion above about "should" vs "must" vs "is" which is a Kool-aid induced distraction from focusing on Behavior during the design phase which is the interesting part.
Missing the point. A fluid interface language that's natural is of a lot of value in Agile/XP. Where do you think acceptance criteria come from? Developers in isolation? Similar tactics, though with less utility (personal belief), are not uncommon in TDD. One such foray was using annotations in JUnit to escape the "test" method prefix for agile dox generation. Sounds great, but it's still leaving @test everywhere. BDD goes beyond this.
I am actually interested in contributing to the creation of BDD tools for PHP, but I would like to get past the Rails is better than Java/PHP/Python style PR campaign and on to a reality-based discussion.
Rails? I don't do Rails. I do Ruby (never learned Ruby just for Rails - I guess DHH would tell me to "F*** Off" in another stupid slide

). BDD was first implemented at a higher level in a Java framework. I used Rspec for Ruby a lot over the last ten months, but BDD is not tied to the language (JCart probably came across Smalltalk's variant of xSpec for example).
Last re-quote:
"BDD is what you're already doing, if you're doing TDD well."
The process is not in question, how it's approached and described is.