Is it possible to use different tables based on previous steps?
So suppose I have something like
When I choose from a <list> of things
And I run a <test> from that thing chosen with special <parameter>
Examples:
|list|
| a |
| b |
| a |
| test | parameter |
| mytest1 | myparameter1 |
| mytest2 | myparameter2 |
| b |
| test | parameter|
| mytest1 | myparameter3 |
| mytest2 | myparameter4 |
Is this possible and what would be the correct structure?
No its not, and it is a very bad idea. Generally when you want to do programming in your scenarios, you should do it by
Giving it a name
Pushing the programming down into the step definitions
In this particular case you seem to want to be doing some sort of exhaustive testing, where you try a single operation under a number of different conditions. Cucumber is not appropriate for this sort of testing. Instead find a way to do these sort of tests at a lower level of abstraction e.g. a unit test.
The main reason for not doing exhaustive testing in Cucumber is the runtime cost. As a rough rule of thumb each integration test (Cucumber) has a run time cost of hundreds of unit tests (maybe thousands of good unit tests).
Related
In our company we're using ansible to target different environments, about 10 on the development and integration side, and 3 on the production side. Those environments have some differences in terms of the number of resources dedicated. For example let say in production we have a standalone server or vm dedicated to run the jvm, another one for dB... And in certain other environments those applications share the same server or vm. The problem is that some playbooks needs to be tweaked in order to target such an environment, so how could we do to make it as generic and transparent as possible?
Thanks for your advices
what you want to achieve is putting good hosts in good groups.
if you're familiar with ansible-inventory --graph, here is what you want to achieve:
#all:
|--#dev:
| |--devel1.domain.org
| |--devel2.domain.org
|--#db:
| |--db1.domain.org
| |--db2.domain.org
| |--dbprod1.domain.org
| |--appprod2.domain.org
|--#app:
| |--app1.domain.org
| |--app2.domain.org
| |--appprod1.domain.org
| |--appprod2.domain.org
|--#dev1:
| |--devel1.domain.org
| |--db1.domain.org
| |--app1.domain.org
|--#dev2:
| |--devel2.domain.org
| |--db2.domain.org
| |--app2.domain.org
|--#prod:
| |--#prod1:
| | |--dbprod1.domain.org
| | |--appprod1.domain.org
| |--#prod2:
| | |--appprod2.domain.org
here the host appprod2.domain.org will inherit from group_vars of app,db, prod,prod2
We are using SpecFlow for functional tests that suppose to replace manual testing when a human reads generated email and validates that all sections match specification. The problem is that Scenario Outlines become to grow to have too many parameters
Scenario Outline: generate and send confirmation email
Given I have stored itinerary in '<EmbeddedItinerary>'
When Generate confirmation email
Then section1 should have parameters '<Param1_1>', '<Param1_2>', '<Param1_3>',...
Then section2 should have parameters '<Param2_1>', '<Param2_2>', '<Param2_3>',..
Then section3 should have parameters '<Param3_1>', '<Param3_2>', '<Param3_3>',...
....
Examples:
| EmbeddedItinerary | Param1_1| Param1_2| Param1_3| Param2_1| Param2_2| Param2_3| Param3_1| Param3_2| Param3_3|...
| Itinerary_1 | Value1_1 | Value1_2 | Value1_3 | Value2_1 | Value2_2 | Value2_3 |Value3_1 | Value3_2 | Value3_3 |...
| Itinerary_1 | Value1_1 | Value1_2 | Value1_3 | Value2_1 | Value2_2 | Value2_3 |Value3_1 | Value3_2 | Value3_3 |...
But the number of columns in Examples would become unmanageable. I wish to have multi-line examples ( but with different reason then in Multiple Multi-Line Examples in SpecFlow Feature File).
The option that I see is to store all ExpectedResults in embedded xml or json resource file, and have SpecFlow features quite small e.g.
Scenario Outline: generate and send confirmation email with correct email address for flight section
Given I have stored embedded resource '<EmbeddedItinerary>'
When Generate confirmation email
Then sections should be as specified in '<ExpectedResultsFile>'
Examples:
| EmbeddedItinerary | ExpectedResultsFile
| Itinerary_1 | ExpectedResults1 |
| Itinerary_2 | ExpectedResults2 |
...
Is it a good idea?
Can anyone suggest better way ( more SpecFlow style)?
My concern is that moving expected data to separate files I am loosing visibility, that is one of advantages of SpecFlow features.
Update: while writing this question I found commercial product ($AUD 255 per user) Specflow+Excel http://www.specflow.org/plus/excel/getting-started/ , which may satisfy my requirement to maintain many columns.
Is it a mature/reliable product? Should I use it instead of own parsing expected results files in proprietary format?
If I have a lot of parameters in a Scenario Outline, I try to work as much as possible with default parameters or split the Scenario Outline in multiple ones.
I think in your case, it should be possible to split the one 'generate and send confirmation email' Scenario Outline in multiple ones that you have a scenario outline for every section.
This would reduce the amount of needed parameters per scenario and you get faster feedback if an error occurs. You immediately see in which section you have an error.
e.g.:
Scenario Outline: generate and send confirmation email - section 1
Given I have stored itinerary in '<EmbeddedItinerary>'
When Generate confirmation email
Then section1 should have parameters '<Param1_1>', '<Param1_2>', '<Param1_3>',...
Examples:
| EmbeddedItinerary | Param1_1 | Param1_2 | Param1_3 |
| Itinerary_1 | Value1_1 | Value1_2 | Value1_3 |
Scenario Outline: generate and send confirmation email - section 2
Given I have stored itinerary in '<EmbeddedItinerary>'
When Generate confirmation email
Then section2 should have parameters '<Param2_1>', '<Param2_2>', '<Param2_3>',..
Examples:
| EmbeddedItinerary | Param2_1 | Param2_2 | Param2_3 |
| Itinerary_1 | Value2_1 | Value2_2 | Value2_3 |
Scenario Outline: generate and send confirmation email - section 3
Given I have stored itinerary in '<EmbeddedItinerary>'
When Generate confirmation email
Then section3 should have parameters '<Param3_1>', '<Param3_2>', '<Param3_3>',...
Examples:
| EmbeddedItirerary | Param3_1 | Param3_2 | Param3_3 |
| Itinerary_1 | Value3_1 | Value3_2 | Value3_3 |
About SpecFlow+Excel: That is also an option. Maintaining examples in Excel is most of the time easier than in the feature- file. It will at least solve your problem in short term, but you have to be also careful to write scenarios that are still understandable and readable.
You can get a trial license for it from here: http://www.specflow.org/request-your-specflow-trial-license/
Full Disclosure: I am one of the developers of SpecFlow+ (Runner & Excel).
I'm doing some optimization work on some database stuff and the system writes down log files. Basically I want to optimize some stuff then restore the original customer db-dump and re-run the whole thing. My log files look something like that:
2016-05-10 15:43:18,135 DEBUG [WorkerThread#0[127.0.0.1:64181]] d.h.h.h.c.d.m... [1517]: doing thing #2081087 took 26831ms
2016-05-10 15:05:18,135 DEBUG [WorkerThread#0[127.0.0.1:64181]] d.h.h.h.c.d.m... [1517]: doing thing #20887 took 4051ms
2016-05-10 15:02:18,135 DEBUG [WorkerThread#0[127.0.0.1:64181]] d.h.h.h.c.d.m... [1517]: doing thing #1087 took 261ms
I want to correlate these events over the different runs now to have some statistical data which change did what. So, what I want is a result like
| run 1 | run 2 | run 3 | ... |
thing #20887 | 261ms | 900ms | 100ms | ... |
thing #1087 | 4051ms | 9000ms | 2000ms | ... |
How can I correlate these events using Elasticsearch and visualize it with Kibana?
I am totally green in those kind of things, I tried reading some tutorials and still couldn't do it on my own.
Here lies the problem: I have 2 files (bulid, compile) which are somehow supposed to take other files and create a working warcraft3 map.
There's an instruction I followed:
To build:_
$ ./scripts/compile # most basic way of calling compile
$ ./scripts/build # most basic way of building a map
build
Script which takes an unportected map and applies any build settings passed via argv
upon on it then turns it into a working warcraft3 map file.
Options | Default | Description
----------------|-------------------------|---------------------------------------------------------------------
env | beta | map environment: each environment has default build settings
debug_script | false | debug this build script
do_jasshelper | true | turns vJass & ZINC into JASS
do_compile | true | turns ../src into out.j. When false, looks for {map_script_path}
do_optimizer | false | uses Vexorian's map optimizer to protect and make the map run faser
do_widgetizer | false | uses PitzerMike's map widgetizer to make map load faster
debug | false | whether the --debug flag should be passed to jasshelper
launchwc3 | false | whether the script should launch wc3 with the map loaded on exit
map_unpro_path | base-maps/{highest}.w3x | the base map file to inject script into
map_script_path | ../out.j | map script path to load into map
map_output_path | ITT_{commit}_{time}.w3x | path where to put the compiled map
setting up
This application requires Ruby
$ git clone git#github.com:theQuazz/island-troll-tribes
$ cd island-troll-tribes
$ scripts/build
It might be a easy thing to do, but I am really bad at this kind of stuff, if someone could explain what to do step by step I would greatly appreciate it
Here is a tricky one regarding Cucumber:
Feature: Some feature
Background:
Given I am on the root page
Scenario Outline: Relevant flash messages should appear
When I fill in some_field with: <name>
Then I should see the text: <relevant_flash>
Examples:
| name | relevant_flash |
| Some name | Some message |
Scenario Outline: Irrelevant flash messages should not appear
When I fill in some_field with: <name>
Then I should not see the text: <irrelevant_flash>
Examples:
| name | irrelevant_flash |
| Some name | Some message |
I hate having to repeat:
When I fill in some_field with: <name>
But for obvious reasons it can not just be moved into background. Or can it? Let me know if you have a workaround...
Well, I can simplify your cucumber with something like this:
Feature: Some feature
Scenario Outline: Relevant flash messages should appear
Given I am on the root page
When I fill in some_field with: <name>
Then I should see <message>
Examples:
| name | message |
| Some name | Relevant message |
| Some other name | Irrelevant message |
| Some another name | another flash message |
You notice that I take out the Background: since we got it cover on Scenario Outline:
I think this steps will run and simple with out too much repeatation
Your Scenario outline could be better organized to avoid duplicate, by combining both successful and failed messages together.
Feature: Some feature
Background:
Given I am on the root page
Scenario Outline: Relevant flash messages should appear
When I fill in some_field with: <name>
Then I should see <relevant_message>
Examples:
| name | relevant_flash |
| Some name | Some message |
| Some irrelevant name | Irrelevant message |
| Name for blank msg | |