Given When Then Testing - Do I NEED a "When"?

Question

I am implementing some smoke tests to our website.

I'm using a Given/When/Then format for existing automated acceptance tests/User stories. But now I want to do an initial smoke test of:

Given I'm on the homepage

Then I should see "Welcome To The Site"

Am I missing something? Is it "ok" to not have a When?

Tools Used: MVC3, SpecFlow, Nunit, Watin

Bernat

see my answer below https://mcmap.net/q/499914/-given-when-then-testing-do-i-need-a-quot-when-quot for the reason you ALWAYS need a "when" – Taillight

Answer 1

It is completely valid syntax to omit any of Given, When or Then (and even to mix them in any order - specflow doesn't care.)

However, for the purpose of readability, rather than omit the When I often rephrase the Given, i.e.

When I view the homepage
Then I should see "Welcome To The Site"

I prefer to omit the Given section, because the When is supposed to indicate what the tested action is.

If the code for the step binding is the same and you want to re-use it, you can always bind your given and my when to the same method.

[Given(@"I'm on the homepage"]
[When(@"I view the homepage"]
public void NavigateToHomePage()
{
     ...

Peeling

Actually Specflow doesn't appear to even care whether you name a step Given, When or Then so long as it binds to the right Given/when/then attribute. The choice of word is flavour, and it seems to just execute the steps in order. – Peeling

It's like perfectionist says; specflow simply execute the steps in the order stated in the feature file. It couldn't care less about which attribute you use. – Sloan

Doh - no newlines in comments! I would recommend using When-steps to clearly mark the action you're testing. As in Arrange Act Assert. – Sloan

this is the right answer. there should always be a when - you have to do something to be able to get the expected result. it's the given that you might not want. if you aren't having to do some setup to get into position to take the action that produced the desired result and can just do the action, then just do the action. the given is the setup that can be omitted. – Jenine

I'll just add that specflow is not the only consumer of BDD specs. There are also human beings who need to be able to read it such as product managers and customers. So even though a specific BDD framework may be lax in its treatment of the input, it's better to stick to the original convention and have Given/When/Then. I do agree for the case above that a good way to write it is When I view the homepage / Then I should see "Welcome To The Site" – Dogy

Answer 2

I think you are really missing the point here. You ALWAYS need a When. That is the thing you should be testing! What you can leave out are the Givens

What you should be saying is;

When I visit the homepage
Then I should see "Welcome To The Site"

Given When Then is really a nicer way of representing a state machine.

Given some initial state // in your case, non
When I perform some action // in your case, visiting the homepage
Then I have some final state // in your case, text displayed to a user

What I like to do is to think about all the things that must be present to allow the When to happen. In your case there doesn't seem to be any initial state. But consider if you had some web application. You would need to have an initial state before visiting the homepage (you'd need to make sure the user is logged in);

Given a user // user must be stored in the database
And the user is logged in // a logged in user must be in the session
When the user visits their homepage
Then the user should see "Welcome To Your Homepage"

An alternative scenario would be;

Given no logged in user // some people would leave this Given out, but I add it for completness
When a user visits their homepage
Then the user should be redirect to the login page

As someone correctly pointed out, most BDD tools don't actually differentiate between Given When Then but you should! The verbose nature of 'Given When Then' has been chosen as its easier for us humans to understand and helps our thought processes. A machine couldn't care less what you call the steps. With this being the case, you should make every effort to utilise the keywords correctly at all times.

Additional

BDD structure is no different to a well set-out test with arrange, act, assert.

The benefit of BDD though is that it gives a verbose structure to tests. This helps devs have domain appropriate conversations with product owners - Behaviour Driven Development.

If you aren't having these conversations, there's very little value in using BDD over normal tests practices.

Taillight

Given/when/then, arrange/act/assert or prepare/execute/verify, the concept is mostly the same: given an initial state (a state you arrange/prepare for the test), when you perform a certain action (you act in a certain way or execute a certain function/method) then you expect a desired behavior (which you have to assert/verify) – Cleisthenes

@RikSchaaf - absolutely. BDD structure is no different to a well set-out test with arrange, act, assert. The benefit of BDD though is that it gives a verbose structure to tests. This helps devs have domain appropriate conversations with product owners - Behaviour Driven Development. If you arent having these conversations, there's very little value in using BDD over normal tests practices – Taillight

Definitely wouldn't hurt to loosely unify the terminology though. And in my opinion BDD can even have value in one-man projects to help structure thoughts on how the code should behave. You could call that a conversation with yourself though though since you'd be filling both the dev and PO role, so technically you're not wrong. – Cleisthenes

Answer 3

I tend to see Given as the equivalent of traditional pre-conditions. When as the equivalent of the test action. And Then as the equivalent of the expected result.

Therefore, if there are no pre-conditions, I would leave out Given and simply focus on When and Then:

When I'm on the homepage
Then I should see "Welcome To The Site"

Specflow will allow you to use Given or When, but Visual Studio will also allow you to write a single class that is 1000's of lines long. Just because both are possible, does not mean either is 'right'.

Fridell

Answer 4

Apologies for the thread resurrection...

I'd have probably gone with:

Given there is a homepage
When I view the homepage
Then I should see "Welcome To The Site"

I like to keep at least one Given, When and Then in each Scenario - don't forget you can also use And and But (not that they're particularly relevant to this scenario). You can even just make a bullet-point style list with *.

Ackley

Answer 5

I would say:

Given I have requested the home page
When the home page loads
Then I should see 'Welcome To The Site'

Placement

Answer 6

You don't need a When. I like the think of the Given/When/Then keywords like

Given - This is a preparation step, do anything you need to be able to perform the test When - This should be an action that your test will verify. Then - This should be where you verify your test based on the action performed in the When steps.

As previously suggestion they only affect the execution order.

Revelatory

Did you really mean to say "You DON'T need a When"? Can you explain why you think that? The rest of your answer seems to suggest a When is important. – Dogy