Our team are reviewing some conventions and need some guidance.
So people would like to have separation between the setup (represented by the Given statement) actions (When) and assertions (Then).
Is it ok to use empty lines between gherkin test steps?
What would be the cons of this approach? Because on the cucumber website there is no rule to not do this.
Feature: Example
Scenario: Multiple Givens
Given one thing <- Setup
And another thing
And yet another thing
When I open my eyes <- Action
Then I should see something <- Assertion
But I shouldn't see something else
You can use empty lines, but I don't think you ever should. Basically if you need the empty lines to make your scenario readable then you should rewrite your scenario to be readable without the empty lines.
The empty lines are a crutch to support scenarios that are too long and haven't had enough work done on them to make them clear and succinct.
Related
I have multiple validations to be done on some web UI. So instead of writing
Then I see "foo" element on the page
And I want the user to see "bar" text
.
.
.
And new order is generated
I want my feature file to be more readable(this might go app-specific and not business specific) and should go something like this
Then following validations are made
* "foo" element is visible
* "bar" text is visible
.
.
.
* new order is generated
My Questions is, '*' keyword has the ability to adapt to any step according to documentation, am I using it correctly? ( I think not because my IDE doesn't think so). What is the correct way of using it?
In other words, how to write steps with * so that IDE understands and recognizes step definition
Let me know if I am not understanding this correctly.
EDIT:
The way I am using '*' is correct, we have to write something like
* "foo" is present
IDE doesn't recognize it may be a problem with the plugin, I wrote the step and the corresponding step definition with any of the standard keywords (Given/When/Then), cucumber recognizes it and works accordingly
The approach I'd use is to find the overall name for all the validations, what are your validations validating?
When you have done that write a single step
Then 'my foo should be valid'
then implement this as something like
Then 'my foo should be valid' do
should_have_valid_bar
should_have_valid_baz
...
end
and then write the helper methods to make this work. This will do the following
Simplify your feature file and make it much easier to read.
Make it much cheaper to add or modify validations.
Transfer responsibility to the programmer.
Simplify your step definitions and reduce their number
In general keep you scnenarios simple and short and don't include detail about HOW things are done. Push that HOW down into step definitions and helper methods.
The GWT should be seen as following:
Given some sort of pre-condition, something kind of setup for the test.
When the action that happens
Then The expected result of the action
the And and But are just representations of the preceding Given, When or Then.
Sometimes, a scenario in this way just is not the best approach (not all jobs need the same tool) and a list of "stuff" is more desirable. i.e.
* Open web browser
* Go to google
* Search for Cheese
* Select a cheese to buy
* go to shop
* buy cheese
* eat cheese
* feel happy
This is where the * should be used to show a list that is a order of instructions. (I'd also be happy to argue that the above could quite easily be written into GWT and that most things can if you understand what you are trying to describe well enough).
I started working with behavior driven tool cucumber. Its a fun tool to use. While i was working on a problem. I came across that most of time, I am not reusing my code.
That's why I want to call a scenario from another scenario. I have searched but found nothing helpful. Can I do that ?
Another same question posted here on github
This may be what you're looking for: https://github.com/cucumber/cucumber/wiki/Calling-Steps-from-Step-Definitions
So there are a couple of things you can do. If you have a step you want to reuse like the following:
Given /^I log in as (.*)$/ do |name|
# ...
end
You can call it within another step like so:
Given /^(.*) is logged in$/ do |name|
step "I log in as #{name}"
end
You can also do the following within a step definition:
steps %Q{
Given I log in as #{name}
}
I came to the same question - and found this post. Maybe it is on purpose that you cannot call Scenarios from other Scenarios. The framework is based on that you think about creating practical Stepdefinitions, so they can be used many times. The basis is to think before creating steps...
I created own Steps vor Login-Method, Pagetransitions to search-page or new File etc..
So in many Scenarios i reuse these Steps - and then add new ones (that can be reused, too).
Now you can think about how big one step should be. You can size it as one action in the testobject or use it as a routine to come to a certain startpoint of your Test over multiple actions. E.G. Given Go to Startpage of creating a security request
Java Code:
#Given ("^Go to Startpage of creating a security request$")
public void GoToStartpageOfCreatingASecurityRequest(){
//logic to get to the demanded point in testobject...
}
So as any other framework cucumber has its limits but they are intended and you have ways to work around it. ;)
Do not forget to use assertions in your test. Wether you use JUNIT or TestNG (I use TestNG). ;)
I'm relatively new to Expression Engine, and as I'm learning it I am seeing some stuff missing that WordPress has had for a while. A big one for me is shortcodes, since I will use these to allow CMS users to place more complex content in place with their other content.
I'm not seeing any real equivalent to this in EE, apart from a forthcoming plugin that's in private beta.
As an initial test I'm attempting to fake shortcodes by using delimited strings (e.g. #foo#) in the content field, then using a regex to pull those out and pass them to a function that can retrieve the content out of EE's database.
This brings me to a second question, which is that in looking at EE's API docs, there doesn't appear to be a simple means of retrieving the channel entries programmatically (thinking of something akin to WP's built-in get_posts function).
So my questions are:
a) Can this be done?
b) If so, is my method of approaching it reasonable? Or is there something stupidly obvious I'm missing in my approach?
To reiterate, my main objective here is to have some means of allowing people managing content to drop a code in place in their content that will be replaced with channel content.
Thanks for any advice or help you can give me.
Here's a simple example of the functionality you're looking for.
1) Start by installing Low Replace.
2) Create two Global Variables called gv_hello and gv_goodbye with the values "Hello" and "Goodbye" respectively.
3) Put this text into the body of an entry:
[say_hello]
Nice to see you.
[say_goodbye]
4) Put this into your template, wrapping the Low Replace tag around your body field.
{exp:low_replace
find="[say_hello]|[say_goodbye]"
replace="{gv_hello}|{gv_goodbye}"
multiple="yes"
}
{body}
{/exp:low_replace}
5) It should output this into your browser:
Hello
Nice to see you.
Goodbye
Obviously, this is a really simple example. You can put full blown HTML into your global variable. For example, we've used that to render a complex, interactive graphic that isn't editable but can be easily dropped into a page by any editor.
Unfortunately, due to parse order issues, EE tags won't work inside Global Variables. If you need EE tags in your short code output, you'll need to use Low Variables addon instead of Global Variables.
Continued from the comment:
Do you have examples of the kind of shortcodes you want to support/include? Because i have doubts if controlling the page-layout from a text-field or wysiwyg-field is the way to go.
If you want editors to be able to adjust layout or show/hide extra parts on the page, giving them access to some extra fields in the channel, is (imo) much more manageable and future-proof. For instance some selectfields, a relationship (or playa) field, or a matrix, to let them choose which parts to include/exclude on a page, or which entry from another channel to pull content from.
As said in the comment: i totally understand if you want to replace some #foo# tags with images or data from another field (see other answers: nsm-transplant, low_replace). But, giving an editor access to shortcodes and picking them out, is like writing a template-engine to generate ee-template code for the ee-template-engine.
Using some custom fields to let editors pick and choose parts to embed is, i think, much more manageable.
That being said, you could make a plugin to parse the shortcodes from a textareas content, and then program a lot, to fetch data from other modules you want to support. For channel entries you could build out of the channel data library by objectiveHTML. https://github.com/objectivehtml/Channel-Data
I hear you, I too miss shortcodes from WP -- though the reason they work so easily there is the ubiquity of the_content(). With the great flexibility of EE comes fewer blanket solutions.
I'd suggest looking at NSM Transplant. It should fit the bill for you.
There is also a plugin called Shortcode, which you can find here at
Devot-ee
A quote from the page:
Shortcode aims to allow for more dynamic use of content by authors and
editors, allowing for injection of reusable bits of content or even
whole pieces of functionality into any field in EE
I've been trying to make something visible only on certain entry_id in expressionengine
{if entry_id="33"}
... show certain content
{/if}
is this even possible in eemcs?
thanks
Sure - but you need to use the {entry_id} variable within a tag pair that provides that variable. For example within a {exp:channel:entires} tag pair.
If you're using url_titles in the URI you may want to think about using segment variables instead. For example:
{if segment_2 == "blog-post"} You're on a blog post{if}
This is what's referred to as a simple conditional in EE, and it's fast enough.
One very important thing to remember in EE is that the standard if:else/else:if routine of an advanced conditional can be very slow, primarily because EE renders all of the code segments and then works its if:else magic. If you find yourself testing many ids or groups, this slows the site down proportionally. In fact, sometimes EEs parse order can stop if:else from functioning entirely.
Instead, consider Mark Croxton's Switchee, a fantastic free plugin that lets you have as many conditions, even nested conditions, without slowdown. It parses just the conditions, then when triggered, is smart enough to descend and run the right code segment:
In Cucumber you define steps which define your BDD syntax; for instance, your test might have:
When I navigate to step 3
and then you might define a step:
When /^I navigate to step (\d+)$/ do |step_number|
# navigate to step ${step_number}
end
Now, all of the above works perfectly fine as is (or at least I think it does). However, you can also do this instead:
When I navigate to step "3"
with a regex:
When /^I navigate to step "(\d+)"$/ do |step_number|
In "The RSpec Book: Behaviour-Driven Development with Rspec, Cucmber, and Friends", author David Chelimsky writes "There are two common styles for steps ... Discuss the pros and concs with your team". On my team a few people have already started using quotes, but it makes invoking steps manually more awkward because you have to escape the quotes inside the step step names (when those step names are themselves wrapped in quotes). However, having quotes makes it more clear where variables are in the Cucumber text.
So, what I'm wondering is: is there any sort of community consensus on what the "right" style is here? Or lacking that ...
Has anyone ever done a benefit comparison between the two styles?
Has anyone used either style extensively?
Ideally I'd like to find out as much as I can before we write a million tests with the "wrong" style ;-)
Seeing as no one is replying to you, I decided to comment - maybe you'll find my opinion helpful.
For example I've been using both styles extensively on a project where there was no "should do this way" in this matter. I think I ended using "(\d+)" style more, because of, like you said:
having quotes makes it more clear where variables are in
As for constructing steps that are composed of other steps, I usually did:
Then /^I fill in my profile information with: "(.*)\/(.*)\/(.*)"$/ do |display_name, picture, description|
And %{I fill in "user_display_name" with "#{display}"}
And %{attach the file "#{picture}" to "user_picture"}
And %{I fill in "user_short_description" with "#{description}"}
end
Hope that helps, I am open for discussion :)