I'm going to flip some of your stuff around, and hopefully I arrive at a point.
On Nov 12, 2007 5:22 PM, David Chelimsky <[EMAIL PROTECTED]> wrote: > On Nov 12, 2007 1:51 PM, Kyle Hargraves <[EMAIL PROTECTED]> wrote: > > and if I'm working in > > a project that tends to use it, I'll stick with it. But in my own > > work, I prefer 'it has 4 entries' > > But it DOESN'T have 4 entries when you write that example. Then it > does when you get the example to pass. But what if the example fails > later on? The example says "it has 4 entries", but that is wrong. What > is correct in that context is that it "should have 4 entries," but > doesn't. And recognizing that gives you some flexibility to ask > yourself whether the object is wrong, or the example is wrong. That > was one of the motivating factors behind the choice of "should", and I > personally find it quite compelling. It probably doesn't matter much. In fact, if you make an imperative statement and the example fails, then the contradiction produces a nasty, noisy, "LOOK AT ME! LOOK AT ME! SOMETHING IS BROKEN! FIX IT" which is generally what you want with unit tests. However... > Secondly, while the Rubinius team is using RSpec (which is great) and > they are writing executable specifications (which is even greater!), > writing a complete specification for an existing language is not > really what BDD is all about. And so while they may be doing something > akin to BDD, or the "language specification flavor" of BDD, it is > really unrelated to the BDD process that the word "should" was chosen > to support. > > The process I'm talking about is an iterative process. Not just > iterative in terms of developing the software, but in terms of > *discovering* requirements of the software as well. The idea is to be > able to respond to change, to check assumptions, and to constantly > redesign the system to align with the requirements as they are > understood to be right at that moment. > > The Rubinius specs are a language specification. The team is not going > to learn during iteration 27 that String#eql should return true for > Strings that are the same except for one character. The spec is > actually a *spec*. It'll take the CEO's signature to change it. In BDD, the unit tests are not the final authority on how the system should behave. I think this is a fundamental difference from traditional TDD. If your specs are failing, that might suck, or it might not. It doesn't necessarily mean anything is broken. Stories are the final authority and let you know when something is broken. But our specs are just a tool to help us design, and sometimes they are a bit more useful by helping us localize issues. (btw, I think that because of that, specs != unit tests. They're very similar, but I'll be so bold as to claim that there are no unit tests in BDD) So, in that sense, I think this ought to be the combination of spec/story for the simple account withdrawal example: Given my savings account balance is $100 And my cash account balance is $10 When I transfer $20 Then my savings account balance is $80 And my cash account balance is $30 (if you look at http://dannorth.net/2007/06/introducing-rbehave you'll see that he uses "should be" for the Then clauses) describe Account do before(:each) do @savings = Account.new 100 @cash = Account.new 10 end it "should transfer $20 to another account" do @savings.transfer_to @cash, 20 @savings.balance.should == 80 end it "accept a $20 transfer from another account" do @savings.transfer_to @cash, 20 @cash.balance.should == 30 end end The description uses "should," thus is gentle and fluid. If an example fails, the developer can choose how to handle it however he wants. The story, on the other hand, must use imperative statements. If it fails, the developer must either fix the code so it passes, or have a conversation with a customer if he feels the requirements may have changed. I hope I didn't muddle anything by using such a simple example. In fact I'm sort of hoping that it gets the point across better...under the hood, the description and spec have virtually identical implementations. The difference is that the story is an authoritative spec of how the system should behave, and the description has no authority at all. Pat _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
