On Nov 19, 3:08     
> This is definitely part of the motivation behind "should."
>
> Keep in mind that BDD started off as an attempt to help TDD newbies to
> understand TDD as a design/documentation practice. The word "should"
> was chosen for a few reasons.
>
> First, it was to get people who were writing test names like test_pop
> to write test names like
> test_pop_should_return_the_object_at_the_top_of_the_stack instead.
> From this perspective, any such word (should, must, aughta, etc) would
> do just fine.
>
> The other motivation for should was in part what Einar suggests here.
>
> If you're writing the test first, then the code doesn't do what it
> should yet. So should makes sense in that moment (before the test
> passes) to say "should."
>
> Later, when a previously passing test fails, when it says "should'
> then you get to ask "should it?" That failure *might* be because a
> code change introduced a bug, or it could be that a new requirement
> nullifies or somehow challenges a previous requirement.

Thanks. This thread has been even more fruitful than I expected. I
truly understand why "should" has been used. Not to say "must" and
others are wrong, of course, but I see how the perspective of
anticipation of code-to-be lends to the use of word "should". It
occurs to me that "expect" is also a good word form this perspective;
and interestingly we see that term being used in both TDD and BDD.

Something else I noticed. Originally I wanted reuse the word "assert"
--I like the word. So instead of 'should' I defined a helper to do:

  e.assert == r

Now, with this new perspective, I figure I'd go ahead and use #should.
When I went to convert it however it didn't quite come out as I
expected, because I had put the expectation first and the actualized
result last. Ie.

  expected.should == result

While this is OK, it doesn't quite translate. It reads much better:

  result.should == expected

That's how we talk about these things.

But then it hits me, trying to make this read well has led to a
potential issue. In Ruby equality is tested by the receiver. If we
make result the receiver then it is the one deciding if it is equal to
the expected. But a robust implementation would have the expected
decide.

I realize this is small minutia to the overall issues involved, but I
thought it was an interesting point nonetheless. It would seem, the
way in which we speak and think about things cannot necessarily be
reflected in the way we write our code.

T.