I realize this is somewhat subjective, but I can't find a good case for one or the other :

it "should do something"
it "does something"

Proponents of the should style mention that it forces you to actually question what it is you are trying to achieve, while detractors find it just redundant.

Is there a consensus on this, or is it purely a matter of style ?


5 Answers 5


Welcome to Legal English.

Using "should" == "shall" == contractual obligation. It's a legalism. It doesn't lead to "questioning". It marks the sentence as a formal contractual obligation.

Using "would" == "will" == nice idea. It marks the sentence as an optional feature.

Questioning is part of facilitation, organization, helping, building trust. Not a consquence of word choice.

Using a bare verb without the modifier makes the sentence slightly harder to highlight as a formal requirement. And in the case of super-complex verbs, it can get a little dicey to figure out how to conjugate it.

Easy -- verbs like "to notify" or "to create".

  • The system notifies via email. (The verb "to notify" is conjugated "notifies" for "the system"--whatever that is.)

  • The system shall notify via email. ("to notify" becomes "shall notify" -- no conjugation. Very simple.)

Hard -- verb phrases like "to log in" or domain-specific verb phrases like "to extract, cleanse, transform, deduplicate and load" or a noun like "prospect" which has been verbed. The longer phrase which has several verbs buried in it is hard to conjugate: conjugate each verb? Or try to conjugate the long phrase as if it was a single word? Since any noun can be verbed in English, it's hard to know how to conjugate those made-up verbs.

  • The system extract, cleanse, transform, deduplicate and loads when the user clicks enter. (English trivially verbs any noun phrase.) Or is it extracts, cleanses, transforms, deduplicates and loads?

  • The system should extract, cleanse, transform, deduplicate and load when the user clicks enter. (The hideous phrase is left intact, no mystery about the verb conjugation.)

["What?" you say, "any noun can be verbed in English?". Yes. Any noun. I'm going to stonewall on that. I've often stonewalled on that. Even the specifications should stonewall on that.]

  • 6
    You say that using "should" doesn't lead to "questioning"; my experience is that it does, especially with people new to testing / TDD. It also has the effect of differentiating outcomes from context and events. "And the order arrives at the warehouse" doesn't tell me if I'm causing the order to arrive by pressing a button, or if it should happen automatically, whereas "And the order should arrive at the warehouse" tells me that this is something I should be checking. BDD is about conversational, not legal, English (or natural language of choice).
    – Lunivore
    Mar 11, 2011 at 18:21
  • 3
    I appreciate that you have different language out there. BDD started in London though... with the word "should" ;) The OP asked whether there was a consensus on this, and there has been since 2004 -> dannorth.net/introducing-bdd
    – Lunivore
    Mar 12, 2011 at 7:27
  • 1
    It's the idea that you use "should" in a legal, non-questioning way that I don't find useful. Kind of the opposite of the deliberate discovery mindset which BDD started with. I spend my life trying to help people who started with "spec" and then feel like they can't question it.
    – Lunivore
    Mar 14, 2011 at 15:48
  • 1
    If you were to edit your answer so that it included something like, "Some people like 'should' because it leads to questioning" instead of what it currently says, which is "it doesn't lead to questioning", I would be very happy. The questioning aspect of BDD is one of the most important, for me, and the way you've phrased this eliminates this aspect rather than providing additional context. Thank you for this conversation, regardless of whether you edit the answer or not; I really appreciate the respectful dialogue.
    – Lunivore
    Mar 15, 2011 at 8:02
  • 11
    The IETF Standard for writing RFCs specifically states that 'MUST' and 'SHALL' are 'REQUIRED', 'SHOULD' is 'RECOMMENDED', and 'MAY' is 'OPTIONAL'.
    – oosterwal
    Mar 15, 2011 at 21:39

Purely a matter of stylistic preference. It boils down to asking, do you/your clients prefer to think about the system in present or future tense?

Qualifiers like "should" or "will" implies future tense, but this is soft and reads well enough when thinking in present tense. Lack of a qualifier definitely indicates present tense (i.e. right this moment).

I prefer using a qualifier because it reads passably well in both cases, whereas lack of qualifier reads a bit strangely during development when everything is future tense.

In any case, if you decide to use a qualifier I strongly recommend using "must" instead of "should". "Should" can be interpreted as being optional (despite S.Lott's assertion to the contrary), but "must" completely removes any ambiguity - must clearly means "not optional".

And because I can't yet comment (karma constraints), this is a response to S.Lott about Should/Shall vs. Would/Will: there's a lot of ambiguity about shall and will, even in legal contract writing. See this article for an explanation.

  • "lack of qualifier reads a bit strangely during development when everything is future tense" - well, if you do TDD and wrote a test but didn't write the code yet, your test fails now. While the semantics of "it is supposed to pass in the future" would mean that it may pass NOW. So present tense brings more clarity, at least in TDD case: it's not a promise about the future that fails, it's the behaviour that's expected NOW that does not hold. Mar 10, 2020 at 9:44

I am in favor of using third person, present tense without a qualifier.

My main argument is that: A test is a story.

A story consists of scenes. Each scene describes:

  • subject
  • context
  • action


DESCRIBE: getReceipt function

CONTEXT: receipt exists

IT: returns the receipt

Just like a good story, a good test is easy to read.

A story tells you what the program does, e.g.

  • begins a transaction
  • makes a request
  • normalizes the response
  • ends the transaction
  • returns the receipt

On the other hand, using a qualifier (does not matter if it is "should" or "must") turns the test into a list of assertions, e.g.:

  • should begin a transaction
  • should make a request
  • should normalize the response
  • should end the transaction
  • should return the receipt

There is no continuous story: your mind is evaluating a list of assertions.

This is subjective, but reading natural language (a story) is simpler than reading a list of assertions.


In my opinion, you should always use 'should'.

Reasoning - with BDD, when you're writing the test, the software doesn't yet do what you want it to do, so saying it "does something" is false. It "should do something", and the tests will pass as long as it continues to do that something.

  • 1
    "Doesn't yet exist" seems to be more reason to use present tense instead of "should". BDD is for acceptance testing and if a system does not yet do something then it ought to fail immediately. There seems to be a divide among BDDers as far as using "should" or not.
    – Brenden
    Jun 3, 2014 at 16:15

From behaviour-driven.org titled "GettingTheWordsRight":

In short, the words that we use to describe things influences the way in which we (and others) think about those things. This isn't just a simple question of being petty about semantics either, as certain words carry with them nuances that affect how we interpret the meaning of a phrase at both an intellectual and an emotional level. Our language is rich with descriptive words and phrases so it seems reasonable to use words that will clearly convey the intention of the elements that we wish to describe in code.

In the case of BDD, I'm personally who almost always uses the word should when naming tests, because its usage implies that while the intention is for a test to provide a certain result, other unexpected consequences may arise which will need to be dealt with if a test result is to be considered valid. You could perhaps use the words expect or must similarly, however these words imply a more imperative viewpoint such that the name of the test could be mistaken to mean "there is nothing wrong with the test, assume the implementation is messed up", whereas *should" implies that the test is likely to be correct, yet may need to be checked again for error if the test results don't seem to add up. I like this, because it influences your thinking such that you are encouraged to keep an open mind as you code, which is very important when you wish to avoid getting stuck as you attempt to debug your code and find yourself looking in the wrong place for errors because of an assumption.

I have however seen the near 'religious' application of the word should fail when it has been enforced as a prefix for test names, as it has forced the programmers involved to go through certain mental and linguistical gymnastics in order to provide a test name that was meaningful, and in such cases it has meant that the intention to get the words right does not meet its expectations, and the tests themselves become difficult to decipher as a result. When this sort of situation crops up, I would usually use the word should at any place within the test method name, to ensure the name conveys its method simply and clearly. I would certainly not however enforce a particular word usage if other words were equally appropriate within a given context. The trick however is to choose words that leave no room for argument about what something represents in code, and that provoke you into thinking about the things that your code is supposed to do without relying on mere implication.

Not the answer you're looking for? Browse other questions tagged or ask your own question.