[Cucumber] A single feature file for UI test and non-UI test automation

['Lancer Kind' via Cukes]

I've got one feature. We did the BDD. We are happy with a nice behavioral
feature file that doesn't explicitly mention the UI, and the team pulls it
into the sprint. With the BDD part is done, it's time for writing test
automation code and feature code.
Since I've only got a little bit of view work and a lot of middle to back
work, I only need one UI test. The other six are going to test via some
API beneath the UI. I'm using CucumberJVM.

What do I do now? Shall I have one feature file work in two "modes"?
Shall I have two feature files that are explicit (one mentions a step
about UI--a little less behavioral) and the other makes explicit it's
testing via "not-ui"?

I've got enough of my own ideas and I'm looking for some more. Let's here
what you'd do no matter how crazy or if you break rules.

[Eric Kessler]

Post by 'Lancer Kind' via Cukes
I've got one feature. We did the BDD. We are happy with a nice
behavioral feature file that doesn't explicitly mention the UI, and the
team pulls it into the sprint. With the BDD part is done, it's time for
writing test automation code and feature code.
Since I've only got a little bit of view work and a lot of middle to back
work, I only need one UI test. The other six are going to test via some
API beneath the UI. I'm using CucumberJVM.
What do I do now? Shall I have one feature file work in two "modes"?
Shall I have two feature files that are explicit (one mentions a step
about UI--a little less behavioral) and the other makes explicit it's
testing via "not-ui"?
I've got enough of my own ideas and I'm looking for some more. Let's here
what you'd do no matter how crazy or if you break rules.

I'd try and take a Bridge Pattern approach. Similar to how Webdriver has a
common interface for automating browsers and a different driver that
implements that interface for each browser type. In your case, make one
driver that performs your behaviors via the API and make another driver
that performs the behaviors via the UI. If you do that, then you will be
able to run all of your tests using either driver depending on whether you
want fast tests that check behavior or slower tests that check for UI
problems.

If you do have behavior that can only be performed via one level of the
application, then you may need to add some hooks/filters so that Cucumber
doesn't try to run UI only tests with the API driver or vice versa.


Eric K

[Andrew Premdas]

Use Cucumber for the UI test, use a unit test tool for the underlying API
code you have uncovered.

This diagram from the RSpec book pretty much sums things up


[image: BDD two circles diagram]

See my answer here
https://stackoverflow.com/questions/28372861/cucumber-js-for-bdd-unit-testing/28441299#28441299
for a bit more detail

Post by 'Lancer Kind' via Cukes
I've got one feature. We did the BDD. We are happy with a nice
behavioral feature file that doesn't explicitly mention the UI, and the
team pulls it into the sprint. With the BDD part is done, it's time for
writing test automation code and feature code.
Since I've only got a little bit of view work and a lot of middle to back
work, I only need one UI test. The other six are going to test via some
API beneath the UI. I'm using CucumberJVM.
What do I do now? Shall I have one feature file work in two "modes"?
Shall I have two feature files that are explicit (one mentions a step about
UI--a little less behavioral) and the other makes explicit it's testing via
"not-ui"?
I've got enough of my own ideas and I'm looking for some more. Let's here
what you'd do no matter how crazy or if you break rules.
--
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
For more options, visit https://groups.google.com/d/optout.

--
------------------------
Andrew Premdas
blog.andrew.premdas.org

[George Dinwiddie]

Lancer,

In https://github.com/gdinwiddie/EquineHoroscope I show an example of
using the same feature file at both the GUI and the API levels.

In
https://github.com/gdinwiddie/EquineHoroscope/blob/master/src/test/java/com/gdinwiddie/equinehoroscope/acceptance/CustomPicoFactory.java
one of two test adapters is used for accessing the system, depending on
the 'testDepth' environment variable.

Note that this is a very simple example. In general I want the same
behavior at both levels, so it makes sense to use the same scenarios. I
do not typically test permutations and edge cases at the GUI level,
though. It's enough that those tests ensure that the GUI is wired
correctly to the API.

See slides 19, 20, & 26 of
https://schd.ws/hosted_files/aab17/b1/Evolutionary%20Anatomy-Agile%26Beyond2017.pdf
There's also a leanpub book (https://leanpub.com/EvolutionaryAnatomy) if
you want the detailed description.

- George

Post by 'Lancer Kind' via Cukes
I've got one feature. We did the BDD. We are happy with a nice
behavioral feature file that doesn't explicitly mention the UI, and the
team pulls it into the sprint. With the BDD part is done, it's time for
writing test automation code and feature code.
Since I've only got a little bit of view work and a lot of middle to
back work, I only need one UI test. The other six are going to test via
some API beneath the UI. I'm using CucumberJVM.
What do I do now? Shall I have one feature file work in two "modes"?
Shall I have two feature files that are explicit (one mentions a step
about UI--a little less behavioral) and the other makes explicit it's
testing via "not-ui"?
I've got enough of my own ideas and I'm looking for some more. Let's
here what you'd do no matter how crazy or if you break rules.

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------