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 :)
Related
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.
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).
Do I have to use Given, And, Then, etc... when I am doing a step definition?
For example in my feature file I have Then I login to the app in one scenario. In another scenario I have And I login to the app.
I don't like all the Then And Given 's in step definitions. Is there a way to not have to specifically use these keywords and use some sort of wildcard? I've thought about just using When in step definitions. I just hate mixing all these keywords when they don't really matter anyway.
I wish I could define the step in my step_definition file without having to use various (meaningless) keywords in front of it.
If you want to change this in your feature file, instead of using one of the step definition keywords (Given, When, Then, And, But) you can use an asterisk (*) in your feature file as a sort of bullet point. Example
Scenario: Test Scenario
* run a sample step
* run a different sample step
This will generate
Given(/^run a sample step$/) do
pending # express the regexp above with the code you wish you had
end
Given(/^run a different sample step$/) do
pending # express the regexp above with the code you wish you had
end
Also, Gherkin supports adding languages, this uses a JSON file to define the keywords for the step. This could be used to change what keywords were used for step definitions.
You could fork Gherkin and clone it. Then edit i18n.json to add a new language which uses whatever keywords you wanted instead of these. It currently supports pirate for example. After this you would either have to submit a pull request for them to add the language definition to the project or build Gherkin yourself from the cloned fork (https://github.com/cucumber/gherkin/blob/master/README.md)
Here is the reference page for adding a language
https://github.com/cucumber/cucumber/wiki/Spoken-languages
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 am creating a menu with the linux utility dialog (see below) and I have heard that it is possible to make a tree-like structure for those checklists. However I cannot find any type in the manpage that creates such a thing? Is it really possible - and if yes: how?
See http://i51.tinypic.com/2ir9qfl.png vs http://i56.tinypic.com/35jasmh.png for how it actually looks like and how it should look like. The original pic was created using dialog --checklist.
First and foremost thank you for the answerz. However the ambiguity of the word 'dialog' and the lack of a correct side by side comparison (couldn't double-check as I was unexpectedly hurried - sorry) made the question difficult to understand.
Hope this helps:
How it looks like: http://i51.tinypic.com/2ir9qfl.png
How it should look like: http://i56.tinypic.com/35jasmh.png
I still want to use the 'dialog' utility - I just want a tree-like view that shows that allows to group some items for better overview. It should be the front-end for a rather complex script that can checkout, compile, fetch and do some other fancy stuff, and the person who wanted me to do this script said that he is sure a tree-like view in dialog is possible as he had seen it before, could however not supply me with the necessary code.
You cannot use the Linux dialog utility to do a single page checklist hierarchy
Instead, create a series of menus to achieve the same semantic structure, far from optimal though, I'll grant you.
The other option is to write a script (in perl/python/ruby perhaps) which uses the ncurses/curses library to build this section of the UI. See here (python example) to help you get started.
Note.
The person who said they had seen a tree like view composed in dialog has either...
Seen it done with a patched/non-standard version of dialog which may exist. (?!)
Saw a custom made ncurses/curses app that provided a similar UI to dialog, hence the confusion.
For more info on ncurses/curses see http://www.linuxselfhelp.com/HOWTO/NCURSES-Programming-HOWTO/
The sample you posted will be difficult to match in formatting, but bash/ksh/zsh all support the select construct, which builds a menu and allows you to process the results of the selection.
PS3="Choose an option "
select opt in start mid end quit
do
case $opt in
start) echo "starting";;
mid) echo "Standing by";;
end) echo "Standing by";;
quit) break;;
esac
done
Example run
1) start
2) mid
3) end
4) quit
Choose an option
1
starting
4
# prompt >
Depending on your requirments, you may need to wrap this a continuous loop, i.e.
while true ; do
select ...
done
I don't think it will be possible to center the question tree as your example.
I hope this helps.
P.S. as you appear to be a new user, if you get an answer that helps you please remember to mark it as accepted, and/or give it a + (or -) as a useful answer.