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.
Related
In Behavior Driven Development style of writing automated functional tests, it is generally understood that Givens should be the pre-condition that the system must be in, in order to begin the test, When should be the user action performed and Then should be asserting whether the observed matches the expected and fail or pass the test accordingly.
Off late my team has started performing assertions in Givens and Whens too which lead me to wonder if this is a correct practice.
For e.g -
Given a user with xyz privileges is logged in
When I click on the abc tab
Then records should be displayed
Should the Given in this test actually assert that the logged in user indeed has xyz privileges or assume the user has required privileges and just perform login
Also should the When assert that tab is visible before clicking?
If "logging in" is a behaviour that's interesting* and you need examples to illustrate it** then it should be a "When", with the context in which it happens being the "Given", and the outcome that results being the "Then".
This is the case for any behaviour you need to illustrate with an example.
However, sometimes it can be useful to make assertions in a Given, just to check that the context really is set up properly. Sometimes when people start adopting BDD the environments can be a bit flaky, and it's handy to know if it's your scenario finding a bug that made it fail, or something earlier in the process. So for that reason, you might find assertions there.
The Given doesn't concern itself with how the system got into that state, though. If it has assertions, it should merely be to check that it is.
Another form I've seen is a check that the system is in the correct state for the context, with corrective action if it isn't.
Note that these are largely interim patterns. They can be helpful while teams are adopting BDD and getting their pipelines and automated deployments into shape.
Assertions which check the results of the "When" are part of the outcome, so part of the "Then". I can't imagine a case where you'd need to check the results of a "When" without it being an outcome. If you've got one, please give me an example.
We discourage using clicking and UI details in scenarios. Work out what you're trying to achieve, and do that. Hide the clicking under the covers.
Most of the time automated scenarios aren't actually there to catch bugs; they're living documentation that helps people think about what they're trying to achieve and what the system already does, thus encouraging good design and preventing bugs in the first place.
I'd say something like "navigate to the ABC tab" and just do it; you'll get a relevant exception if it isn't there, and that won't happen as often as people reading the scenario will.
* It's logging in. It probably isn't.
** It's logging in. You probably don't.
Assertions in Givens and Whens are generally an indicator of immaturity of step definitions. So I might put one in a step that I am working on, but I wouldn't keep it there for very long.
I'd implement your step
Given a user with xyz privileges is logged in
as something like
'Given a user with xyz privileges is logged in' do
user = create_user(privileges: xyz)
login_as user: user
end
I would expect that the create_user method would be trusted pretty quickly and would not need an assertion. Same for the login_as method. (if methods like this aren't working properly you'd expect many scenarios to be broken)
Notice how this code makes it clear that there are two things going on and provides/uses an api that you would expect many other stepdefs to use. And how any assertion you might want to keep really belongs in the helper methods not in the step def.
There are no strict rules however in my experience I find it handy to define that there are no assertions there so it is clear what is actually tested and the test itself will run faster.
In the case if your abc tab is not displayed it shouldn't be clickable and then the test will fail either when identifying the object to click or when performing the next step(depends on the tools and method you use).
However you should make sure that the actual implementation of the test is not cheating and working with internals that are able to trigger a click even if the actual component isn't.
There is another point about the Given, there normally it is recommended to set up the environment for the test. This means you make sure that in your system there is a user and that user has been logged in. It makes no meaning to very that as you set it up, however if any failure occur you should fail fast to know what is wrong.
Generally I would be careful about using assertions in the Given or When steps in the automation code.
However, I use login steps like this all over the place in my code as - when used correctly - can turn the step into a piece of context rather than an assertion itself.
For instance:
Is this user logged in?
Yes => Do Nothing.
No => Log out, then Log in as this user
In the example you gave, we know that we need the specific user to be logged in for this scenario to work, however we do not know if there is a different user logged in (other scenarios may have been run before it). If you use this step as a check to make sure that the correct user is logged in (as in my example), it is part of the context and it will speed up run time of the automation as you won't have to log in before and log out after every scenario.
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.
I have a feature file A.feature which generates a number in the response body. Now, I have to capture that text/number and then pass it as test data to another feature file.Do we need to write step definition or is there any other way?Please suggest.
Generally, you should not do that. In fact you should try to make your test cases totally independent from each other. It's a bad sign if a single code change breaks many of your tests (in your case, whenever the first feature breaks, the second one would as well.) It's also a bad sign that, as a starting point, your second feature needs a special response that is not easy to construct.
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.
I am new to Cucumber and BDD. I was wondering if there is a good way to specify a condition that must be checked after every step. For example, suppose I want to make sure a particular variable x is equal to 5 after every step. I do not want to write the scenario like this:
When something happens
Then x should be 5
When something else happens
Then x should be 5
And so on...
Is there a less repetitive way of accomplishing this? I am aware of Background and hooks, but these seem to be for setting up the environment rather than verification.
Use the AfterStep-hook (see https://github.com/cucumber/cucumber/wiki/Hooks). This code will run after every step.
Alternatively you can decorate the scenarios with tags an just have the hook run for after steps in the tagged scenarios