Head On

An interesting notion. Though I like the "should"-convention it can at times feel a little forced. I can see your point in Must and Won't, but I have a little problem with Could. It seems too weak to be of any value.
Looking through the code of one of my current assignments I realized that we've used "should" in aprox. 90% of the cases and "test" in the other 10%. Slightly surprised. I didn't think that we were so steadfast in our naming. Perhaps we shouldn't be?

Or you could define 'should'...

http://www.ietf.org/rfc/rfc2119.txt

If I remember correctly Dan North is very fond of saying that language matter, a lot, and from what I remember of him describing the history of BDD and the epiphany of "Should" it had quite much do to with the fact that "should" evokes dialogue. As you put it in your post "“the title of the index page should be ‘blabbr.com - the worlds largest social network’" reading the test name ""Shouldhaveindexpagewithtitleblabbrcomtheworldslargessocialnetwork()" you can in essence say, "No it shouldn't". And change both the test and the implementation to match, the testname "TestIndexPageTitle" needs much more context to figure out what it's doing, and even when you do the whole test business seems to make us inclined to read "MUST" into the whole thing and make the majority of us qutie reluctant to change it. Should seems to be vauge enough for us as people to question and discuss about. It also has the fantastic property that it's quite easy to figure out what you're supossed to be driving at when you're set to write the next test, and ask your pair "so what should this fella do next" and you get the answer "Well now the Frooble should Brobble the Thingmajig", if you're a fast typist you already have the corrosponding "ShouldBrobbletheThingmjigwhen_something()" and you're set to go. The question "Wha't the next test?" seldom leads to "BrobbleThingmajig()" in the same fluent manner. This also works if you're alone, any time you need to start thinking about where to go next it's often quite convinent to just start with well now Frooble should... and something almost always appears.

Basicly my view on "Should" is that it's a catalyst for dialouge and an often needed invitation to discuss and explore the domain, the actors and their responsibilities. And I guess that sometimes we arrive at things that really "must" happen or "won't" happen, and I can't find a sensible reason to not use that phrasing if that's what we really mean, it really seems silly to get stuck in dogmatic use of should, espicially given that the outset of the whole thing is that language matters, limiting ourself to a single epxression seems to me, very strange in that situation.

I propose that we start advocating that our tests should "SWiM" that is they should specify theese things:

Should - the SUT "should" do this. "Should have page title"
Won't - the SUT Won't do this. "Won't call the database"
instruct - the SUT is used in this way. Learning tests, samples.
Must - the SUT Must do this. "Must shutdown reactor when overheating"

Steve,

BDD is all about conversation, and people already have their own definition of 'should'. Let's work with that instead of redefining the meaning.

Torbjörn, I totally agree with the notion that 'should' encourages dialog. Use it as much as possible when discussing features. However, the specs also acts as documentation of design decisions, and as such they should convey as much information as possible.

Måns, why mix 'should' and 'test'? To me that sounds like the 'test' once are written after the implementation, I am wrong?

A slightly better formated version of the SWiM comment can be found here: http://torbjorn-gyllebring.blogspot.com/2008/11...>

I like it. I have had this weird feeling about 'should'...

"It should, but i does not have to"

"shall or must" are more static...

interesting...

Interesting idea - I guess there would be value in the Must, Should and Won't, not sure about the Could though, that would be very vague.

I suppose Won't is the opposite of Must but then it seems to close the discussion on whether or not the assertion made after the Must/Won't is actually valid. In the nuclear example you gave clearly that makes sense but the systems I've worked on at least aren't as clearcut and things that seem 'definite' can change, hence the value of the 'Should' idea.

Mark

The reason for the mix of should and test, in this case, was due to the fact that not all code was written when pairing and some people simply felt more comfortable using test in the beginning of the project (probably due to previous JUnit 3 experience). Old habits die hard. However I think that some of the tests/designs could have been written after the fact.