I think it’s also important to differentiate between what the specification wording says and what the testing does. Either that or we end up writing multiple sets of tests that duplicate 95% other than stringency. My point is that the should method trickery has no tolerance (except in one case) for deviation, why should the language?

As repeated in countless other places, TDD is not abut testing. At least BDD is not. It is about design.

I think that using the word “should” in the process of designing code with RSpec keeps the programmer in a more exploratory and critical mindset than whith the moe dogmatic “must”.

Maintaining and evolving software also means maintaining specs, and this is a lot like gardening. The specs have to be trimmed and watered regularly, and sometimes they die – because they’re old.

This is a good thing. It is a sign of a software system that is alive and adapting to external forces.

Having specs that say “should” supports this kind of evolution, because it’s easier to ask the critical question: “Should it really?” and then perhaps end up changing or even deleting the spec.

If the spec said “must” people would be more hesitant to change the spec, which is actually bad – it’s the opposite of embracing change: rejecting change.

I believe that the concept of up-front and rigid requirements specifications only works in very few domains in computer science. I have never worked in an environment where requirements don’t change.

This is why I am more in favour of “should” than “must” in most cases. It may be a different case with specifications of protocols – they are much more rigid and can’t change as easily. But very few people write protocols.

Chris Petrilli provides some excellent commentary on language and phrases used in specification and requirements documents. Over the course of my career producing specifications, requirements documents, project charters, etc. I have come to favor very …