I am using cucumber-jvm and writing BDD tests.
I would like to write the step definition for "Then I should see three posts on a page" (The class name is Post)
So my best guess is:
expect(page).to have_css("tbody tr.#{Post}", count: 3)
But that does not work
how about:
element = all("tbody tr.#{Post}")
element.count
That should do the trick...
Related
I'd like to do something like this:
These are the problems:
1. Too much concrete
2. Too few plants
...
This was also stated in Problem 1 and Problem 2.
The "Problem 1" and "Problem 2" should be links to the list above.
Output
syntax
These are the problems:
. [[prob1, Problem {counter:prob}]] Too much concrete
. [[prob2, Problem {counter:prob}]] Too few plants
This was also stated in <<prob1>> and <<prob2>>.
Explanation
prob1 and prob2 are IDs for the problems. You can freely choose them. E.g. prob_concrete and prob_plants. That way they would be easier to use.
{counter:prob} is the syntax for counting the counter called prob. You can freely choose the countername. (See "Counters" of the documentation)
Problem {counter:prob}: This is the part, that defines, how the reference is shown, when used (see image above).
I am working on Verigy 93K test program and I have a logic that I would like to know if there's an equivalent code in Origen.
I am working on Verigy 93K test program and I have this logic (IF condition) that I need to insert in my flow.
Basically, I have a variable called 'INSERTION' and this will have different values like 'GCORR', 'VCORR' and others.
I would like to know if there's an equivalent code like this in Origen.
I attached a snapshot, hope that it can help clarify my question more.
In this logic, I would like to check the INSERTION value and if the value is not equal to GCORR or VCORR, the logic should pass, else, fail.
Here is the screenshot:
This pull-request adds an official API for this.
This example would be implemented as:
whenever_any ne(:INSERTION, 'GCORR'), ne(:INSERTION, 'VCORR') do
# Your tests in here
end
That would produce something logically equivalent and which can be re-targeted to other platforms.
If you don't care about that and want to produce exactly as you have it in the above example, then this should work too (where the OR is hard-coded for V93K syntax):
whenever ne(:INSERTION, 'GCORR|VCORR') do
# Your tests in here
end
Here is the preliminary documentation of this feature from the above PR - https://github.com/Origen-SDK/origen_testers/blob/66345c9422d9fa6b2577af20110259e45c2bdd26/templates/origen_guides/program/flowapi.md.erb#L71
I couldn't find api support on flow control or variable values beyond "if/unless_enable" support which can help check for 1 or zero. One way is to use render.
render 'if #INSERTION != "GCORR|VCORR" then'
render '{'
# your code for non-GCORR_VCORR flow
render "} \n else \n { \n } "
In Cucumber you can write Then expressions and their step definitions to verify the results. The problem is I don't want to write 2 different step definitions for checking the outcome. One example would be like this:
Then the transaction is successful
and
Then the transaction is not successful
How can I get around this?
I've found out that in Ruby you could consolidate step definitions by using capturing optional groups as described [here]. That is:
Then /^I should( not)? see the following columns: "([^"]*)"$/ do |negate, columns|
within('table thead tr') do
columns.split(', ').each do |column|
negate ? page.should_not(have_content(column)) : page.should(have_content(column))
end
end
end
But I don't know whether this is possible in Java or not. And even if it is what type of variable should I be capturing?
Why not write two step definitions. Each one is simpler, on topic, doesn't require a regex. If you delegate the work the step definitions do to a helper method you can remove almost all of the code duplication as well
Then I should see the following columns |cols|
should_see_cols(cols)
end
Then I should not see the following columns |cols|
should_not_see_cols(cols)
end
Now you have super simple crystal clear step definitions and you can write your method/ methods however you want.
Step definition duplication is irrelevant if all your step definitions just make a single call to a helper method. You can be as DRY as you like with your helper methods and still keep your scenarios super simple and remove the need to use regex's and complex logic in your step defs.
In Java, I would create one method with capture groups (is|is not), and derive a boolean from that which I would compare to the value. On the other hand, this adds logic to your test implementation so there is something to be said for #diabolist's solution of having 2 distinct step definitions.
I was wondering about some best practices regarding extraction of selectors to constants. As a general rule, it is usually recommended to extract magic numbers and string literals to constants so they can be reused, but I am not sure if this is really a good approach when dealing with selectors in Capybara.
At the moment, I have a file called "selectors.rb" which contains the selectors that I use. Here is part of it:
SELECTORS = {
checkout: {
checkbox_agreement: 'input#agreement-1',
input_billing_city: 'input#billing\:city',
input_billing_company: 'input#billing\:company',
input_billing_country: 'input#billing\:country_id',
input_billing_firstname: 'input#billing\:firstname',
input_billing_lastname: 'input#billing\:lastname',
input_billing_postcode: 'input#billing\:postcode',
input_billing_region: 'input#billing\:region_id',
input_billing_street1: 'input#billing\:street1',
....
}
In theory, I put my selectors in this file, and then I could do something like this:
find(SELECTORS[:checkout][:input_billing_city]).click
There are several problems with this:
If I want to know the selector that is used, I have to look it up
If I change the name in selectors.rb, I could forget to change it somewhere else in the file which will result in find(nil).click
With the example above, I can't use this selector with fill_in(SELECTORS[:checkout][:input_billing_city]), because it requires an ID, name or label
There are probably a few more problems with that, so I am considering to get rid of the constants. Has anyone been in a similar spot? What is a good way to deal with this situation?
Someone mentioned the SitePrism gem to me: https://github.com/natritmeyer/site_prism
A Page Object Model DSL for Capybara
SitePrism gives you a simple, clean and semantic DSL for describing
your site using the Page Object Model pattern, for use with Capybara
in automated acceptance testing.
It is very helpful in that regard and I have adjusted my code accordingly.
I am using watir-webdriver (0.5.3) in a Cucumber (1.1.9) test. I am attempting to verify the text value of an <acronym> tag. The code is legacy, and there are plans to change it to a <div> or <span> tag, but in the mean time I have to deal with it. I first attempted:
#browser.acronym(:id => /expense_code(.*)/).text
I received the following error:
NoMethodError: undefined method `acronym' for #<Watir::Browser:0x33e9940>
I poked around in the Watir code to see how tag objects were being created, and found that they seem to be dynamically created based on the HTML5 spec, but then I also found a comment in element.rb stating that they are no longer being created from the spec. At any rate, I couldn't see an easy way to inherit a <span> object and call it an <acronym> object. So, I looked into alternatives, and found the element object.
#browser.element(:id => /expense_code(.*)/).text
This code works, but it takes about a minute to traverse my page. I'm stuck with the regex for now, as the tag id is actually dynamically generated and I don't currently have a way to figure out those values. This is what the tag actually looks like:
<acronym class="editable select fillwith:exp_codes default:E100"
title="Expense Code: Expenses" id="expense_code114_582_10777">
E100 </acronym>
I would appreciate any thoughts on how I can improve the performance of my test.
Is that class name predictable? could you construct that from a set part plus the text you are about to validate (it's the same in your example above) and go that way?
acronym = 'E100'
browser.element(:class, 'editable select fillwith:exp_codes default:#{acronym}'.text.should == acronym
Does using XPath to limit the elements to just acronym tags help performance?
#browser.element(:xpath, "//acronym[contains(#id, 'expense_code')]")
UPDATE: As Chuck mentioned, CSS-Selector is also an option:
#browser.element(:css => "acronym[id^=expense_code]")
I was recently stealing logic from Watir 1.6.5 to make custom locators/collections for my page objects and I noticed in the Watir::TaggedElementLocator, it kind of supports any method that the element supports. Noticing in Watir-Webdriver that elements have a tag_name() method, I thought I would try the same and it looks like it works.
So you can use tag_name as a locator by doing:
#browser.element(:tag_name => 'acronym', :id => /expense_code(.*)/).text
I'm not sure what order the locators get run in, so since the regex is expensive, it might be faster to get all the acronym elements and then find the one with the right ID:
#browser.elements(:tag_name, 'acronym').find{ |acronym|
acronym.id =~ /expense_code(.*)/
}.text
While I think it makes the code look better, unfortunately I'm not sure if its any faster. I am guessing the performance of each will depend on the specific page layout being tested.
I'm not sure what the proper etiquette is here, but this is the answer I came up with using Chuck's reply and feedback from jarib in the #watir IRC chat. With all my examples, expense_code = 'E100'.
#browser.element(:tag_name => "acronym",
:class => "default:#{expense_code}").text
The above code works at a very reasonable speed and doesn't require an xpath. It is a shortening of the following code:
#browser.element(:tag_name => "acronym",
:class => "editable select fillwith:exp_codes default:#{expense_code}").text
I learned that I didn't need to pass the whole string. Anything in a class delimited by a space is dealt with gracefully by watir. I adapted that code from this xpath:
#browser.element(:xpath => "//acronym[contains(#class,
\'editable select fillwith:exp_codes default:#{expense_code}\')]").text
The gotcha in that code above was needing to escape out the ' around the class values so that it would evaluate correctly.
Just searching for the class (code below) did not work. I have no idea why. I did notice that it pounded the database with requests. Whatever it was doing, the page didn't like it. Though the reason it was trying multiple times is I slipped a wait_until_present in there.
#browser.element(:class, "editable select fillwith:exp_codes
default:#{expense_code}").text
Thanks for the help. :)