I have a specific scenario as follows:
if (element shows up on UI)
validate it
else
no harm done; move on...
If I know upfront if the element shows up or not, I can frame two different scenarios, when the element shows up and when not.
But, in this case, it may or may not be present. If it is present, it should function as expected.
Any suggestions on how this can be implemented in a Cucumber scenario(s) ?
I am using Cucumber-jvm.
You have two separate scenarios, you just need to be able to make sure you setup the preconditions to assume one scenario vs the other.
In general, you should not be implementing a conditional inside a single scenario, because your intent is to test two scenarios.
Related
Extending the question Cleanup steps for Cucumber scenarios. I am aware that I can use tagged #After hooks to repeat the last few steps for all scenarios matching the tag. However, this implementation will be in my java classes and my business users will have no idea. Also my acceptance tests are huge, around 200. Lets say each feature file contains 10 scenarios and last 3-4 steps are common for all of them in that feature file. So i will have 20 feature file and 20 unique tags. I can create 20 #After hooks function and silently perform those steps. But how will my business owners know this if they cannot see these technical implementation?
The purpose of 'Background' tag is to repeat the same steps at beginning of the scenarios. We could have easily achieved this by using tagged #Before hooks, then why Background tag? If we have new feature of having 'Postground' tag, which is opposite of 'Background' tag, above problem can be solved. What do you think?
Note: I have logged an issue for this, but it got closed by #aslakhellosoy. I think I did not articulate the problem statement well.
Instead of repeating the same steps one by one, you can extract helper methods to perform the individual actions those steps perform, and call those helper methods either one by one in individual steps, or in sequence from the overarching step.
That way you can still make visible to the business users what happens, without having to spell out all the individual steps.
For more information, check the Cucumber documentation on Helper Methods.
If you still have more questions (I realise the documentation on Helper Methods isn't very extensive), please join the Cucumber Slack.
I am a newbie to cucumber and I haven't found yet a way to interrupt cucumber scenario by condition. I'm trying to implement some scenario:
Scenario: Check some value
When get some value if it's present
Then parse this value
And check value #1
And check value #2
And check value #3...
I have several steps for several value checking and I want to skip all of the checks if value is empty, but I don't want the scenario to be failure in that case. Can anybody please give an advise of implementing that case?
Why would you want to write a scenario like this. As you are in your test environment you have control over whether the value is present or not. The presence/absence of that value is indicative of some previous behaviour. So you have two scenarios
Scenario: Something has happened and the value is present
Scenario: Something has NOT happened the the value is absent
In the first scenario you can do you extra checks and if things pass you know things are OK. In the second scenario you know you don't need to do your extra checks so you can do something else instead.
You never want to have scenarios pass when they should be failing. If you need some sort of IF statement in your scenario you need refactor and extract additional scenarios.
I am reading a lot about Gherkin, and I had already read that it was not good to repeat steps, and for this it is necessary to use the keyword "Background", but in the example of this page they are repeating the same "Given" again and again, Could it be that I am doing wrong? I need to know your opinion about it:
Like with several things, this a topic that will generate different opinions. On this particular example I would have moved the "Given that I select the post" to the Background section as this seems to be a pre-requisite to all scenarios on this feature. Of course this would leave the scenarios in the feature without an actual Given section but those would be incorporated from the Background section on execution.
I have also seen cases where sometimes the decision of moving steps to the Background is a trade-off between having more or less feature files and how these are structured. For example, if there are 10 scenarios for a particular feature with a lot of similar steps between them - but there are 1 or 2 scenarios which do not require a particular step, then those 1 or 2 scenarios would have to moved into a new feature file in order to have the exact same steps on the Background section of the original feature.
Of course it is correct to keep the scenarios like this. From a tester's perspective, the Scenarios/Test cases should run independently, therefore, you can keep these tests separately for each functionality.
But in case you are doing an integration testing, then some of these test cases can be merged, thus you can cover multiple test cases in one scenario.
And the "given" statement is repeating, therefore you can put that in the background, so you don't have to call it in each scenarios.
Note: These separate scenarios will be handy when you run the scripts separately with annotation tags, when you just have to check for a specific functionality, or a bug fix.
Recently, while looking for a job change on manual QA, I had interviewed on regular testing concepts questions. But, in a few companies,they gave some scenario and asked to write test case enumerations for it. Is it like test steps I need to write.? As per my knowledge, enumeration means complete, ordered list of all the items in a collection, so, is it writing all the test steps with description.?
Listing all possible test case names which could be extracted out of the scenario provided and classifying them in terms of priority and positive/negative/types is test case enumeration.
Kindly comment if you need anything, here is an example for better understanding.
Enumerate test cases for Login:(Classifying priorities into P1>P2>P3)
Positive cases include:
P1-Verify the login dialog box
P1-Verify the login id
P1-Verify the password
P1-Verify the submit button
Negative cases include:
1. P3-Verify logging in with empty id and password fields
Note: Haven't covered all the test cases.
Test Enumeration orders those scripts one by one- like 1,2,3... etc present in the test suite.It is just like defining the priority with which you want to run a specific script in a test suite.
For me enumeration means give for each test case identifier which is no 1, 2, 3 etc but which can tell you something, for example in very simple project you have three modules Users, Orders, Reports you can enumerate your use cases User.Accounts.1, User.Accounts.2..., User.Roles.1, User.Roles.2, Orders.Add.1, Orders.Edit.1, Orders.Edit.2, etc.
I gave long identifiers but you can short it or even replace names by numbers.
Other way (which is even much clear) you can gave names to use cases:
User.Accounts.Add account
User.Accounts.Edit account
User.Accounts.Remove account
User.Accounts.Remove account - negative (cannot remove)
User.Roles.Add role
etc...
This helps you (and others) to see if list of test cases you planned is full or you should add some new.
Begging a pardon in advance for a newbie question.
I'm writing a feature where visitor of the page should see several attributes of an item.
The question is shall I add a separate feature for each attribute or separate scenarios of the same feature or create a single column table in then clause listing all attributes that should be displayed?
I'd put all of the assertions in the same scenario unless there's a good reason to separate them. It would take a lot longer to run if it has to get to the page to assert on multiple times.
The decision to use multiple 'Then ...' lines or to use a table is mainly a matter of personal taste as both will work. Personally if there are only a couple of assertions then I just use multiple Then lines, but if there are more than that I use a table.