How to state OR in a test

[Mark Olliver]

Hi,

I am looking to use Gherkin/Cucumber to check is servers that are provided to me meet predefined settings before I accept them to work on.

For example one test I want to do is check if the server has a supported OS from a list of versions that I support. Looking at it normally this would be a scenario with a table of options, but as far as I could tell that would then run a test for each scenario which would see at best all bar one fail whereas If one combination passes then the test is a pass as you can not have all the supported OS's on the same server. 

My issue is I am unsure how to define this as a test. So far I have:

Feature:

  Scenario: Check Supported OS

  Given a file named "/etc/redhat-release" exists

  When I read the contents

  Then I see one of "CentOS 6.5|CentOS 6.6|Redhat 6.5|Redhat 6.6"

Thanks

Mark

p.s sorry if this issue appear twice but it looks like my first attempt did not appear.

[Andrew Premdas]

On 24 April 2015 at 16:47, Mark Olliver <pixi...@gmail.com> wrote:

Hi,

I am looking to use Gherkin/Cucumber to check is servers that are provided to me meet predefined settings before I accept them to work on.

For example one test I want to do is check if the server has a supported OS from a list of versions that I support. Looking at it normally this would be a scenario with a table of options, but as far as I could tell that would then run a test for each scenario which would see at best all bar one fail whereas If one combination passes then the test is a pass as you can not have all the supported OS's on the same server. 

My issue is I am unsure how to define this as a test. So far I have:

Feature:

  Scenario: Check Supported OS

  Given a file named "/etc/redhat-release" exists

  When I read the contents

  Then I see one of "CentOS 6.5|CentOS 6.6|Redhat 6.5|Redhat 6.6"

Thanks

I would do this as

Scenario: Server should have supported OS

  Given I have a server  # adjust this to meet your needs

  When I check the server for a supported OS

  Then I should find a supported OS

Cucumber/Gherkin is about expressing the what and why, (which you did very eloquently in your mail), the details of how aren't needed in the feature. Instead put them in support methods

e.g.

module ServerStepHelper

  def supported_os_s
   [

      centos_6_5,

      centos_6_6,
      ...

   ]

  end

  def check_release(release, server)
   ...

 

end

World ServerStepHelper

and use these support methods in your step definitions e.g.

When "I check the server for a supported OS" do

  # I'd actually extract this code into a helper method, but I've left it here for this example

  supported_os_s.each do |os|

    check_release(os, @server)

  end

end

Then when you add support for another OS (which you will), you only have to change one thing, instead of lots of Gherkin.

Andrew

Mark

p.s sorry if this issue appear twice but it looks like my first attempt did not appear.

--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

------------------------

Andrew Premdas

blog.andrew.premdas.org

[Richard Lawrence]

I agree about adding the domain concept of a "supported OS" and doing the comparison in the step def. If the list of OSes is an important business concept, though, I'd express it in the scenario using a table arg, along the lines of:

Then the server should have one of the following supported OSes:

| Distribution | Version |

| CentOS       | 6.5     |

| Redhat       | 6.6     |

or if you use the notion of supported OSes in multiple places, you might do this in a Background (setting up the array like Andrew suggested) and just refer to the concept by name later:

Given the following supported OSes:

| Distribution | Version |

| CentOS       | 6.5     |

| Redhat       | 6.6     |

The list is still in one place, only now it's in the feature rather than the step defs. If it's a business concept, put it in the feature. If it's an implementation detail, put it in the step defs.

Richard

[Andrew Premdas]

Its not if the list of OSes is an important business concept, it is

" If the exact composition of the list is an important business concept and if changing a member of the list would fundamentally change the underlying business concept."

Even then it would be better to encapsulate in some way, e.g. by naming why

  centos 6.5, redhat 6.6

is fundamentally different from

  centos 5.5, redhat 5.6

In general all tables of examples can be extracted into a domain concept, and in the long term lifespan of a feature, finding, naming and documenting that domain concept in the feature gives much greater value than having a list of examples. I do except that in the early lifespan of a feature example tables can be useful in uncovering domain concepts. However once the domain concept is uncoverd and undestood then the set of features as a whole benefits greatly from the removal of example tables.