On Tue, Nov 18, 2008 at 7:46 AM, Einar Magnús Boson
[email protected] wrote:
don’t know enough about BDD. Especially when you use tests to design
interfaces the “should” thinking comes more natural: You don’t have a
feature yet but you write down what it should do, then you implement it.
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.
FWIW,
David