I have a cucumber scenario where I wan to test for an HTML tag.
Scenario: enter words
Given I enter "cat,dog"
When I set tag to "li" and the class to "word"
Then I should see "<li class=\"word\">cat</li>"
And I should see "<li class=\"word\">dog</li>"
Is this the correct way to write this scenario?
You should aim to have your scenario's read in plain english. If I weren't a developer then the scenario wouldn't make much sense to me. You could do something like this:
Then I should see cat within a word list element
The step for this would be:
Then /^(?:|I )should see "([^"]*)" within (.*)$/ do |text, parent|
with_scope(parent) do
if page.respond_to? :should
page.should have_content(text)
else
assert page.has_content?(text)
end
end
end
The cucumber generator should already provide the with_scope method but here it is anyways:
module WithinHelpers
def with_scope(locator)
locator ? within(*selector_for(locator)) { yield } : yield
end
end
World(WithinHelpers)
And just be sure to add the selector to your selectors.rb in features/support/selectors inside the case statement for locator:
module HtmlSelectorsHelpers
def selector_for(locator)
case locator
when ' a word list element'
'li.word'
Related
I'm using the Cheezy Page Object gem (which also means I'm using Watir, which also means I'm using Selenium). I also have the watir gem explicitly loaded.
Anyway I have a site I am modeling with the UI written in angular where there is 1 page whose contents change based on dropdown selection. The page has several sections but it is visibly the same for each dropdown choice. The only difference is the xpath locators I am using to get there (there's no unique ID on the sections).
So for example I have an xpath like html/body/div[1]/div/div[1]/div/**green**/div/div[1]
and another like
html/body/div[1]/div/div[1]/div/**red**/div/div[1]
The elements on the sections strangely all have the same ID attribute and same class name. So I've been using xpath for the elements since that appears to make it a unique locator.
Problem is there are currently seven dropdown choices each with several sections like this. And they have visibly same elements and structure (from end user perspective) but when you look at html the only difference is the locator so like this for the elements:
html/body/div[1]/div/div[1]/div/green/div/div[1]/**<element>**
and another like
html/body/div[1]/div/div[1]/div/red/div/div[1]/**<element>**
In my current design I have created one page and created page sections for each section on a page. Multiply the number of page sections with number of dropdown choices and you see it is alot. Some of the choices do generate extra elements but there are still common elements between all sections. I also have to duplicate all of these elements across the seven different pages because the xpath is different. Is there some way for me to pass some initializer to the PageObject page_section like the type-a or type-b string and then based on that I can also choose correct xpath for all elements?
So like if I have text field like so in like a base page object page_section:
text_field(:team, xpath: "...#{type_variable}")
Can I do something like section = SomePageObject.page_section_name(type_variable)?
EDIT: Adding Page Object code per request
class BasePO
include PageObject
#Option S1 Cards
page_section(:options_red_card, OptionRedCard, xpath: "/html/body/app-component/app-page/div[2]/div/div/div[1]/div/div/div/ngb-tabset/div/div/red/div[2]/div[2]/div/div/div/div")
page_section(:options_green_card, OptionGreenCard, xpath: "/html/body/app-component/app-page/div[2]/div/div/div[1]/div/div/div/ngb-tabset/div/div/green/div[2]/div[2]/div/div/div/div")
page_section(:options_yellow_card, OptionYellowCard, xpath: "/html/body/app-component/app-page/div[2]/div/div/div[1]/div/div/div/ngb-tabset/div/div/yellow/div[2]/div[2]/div/div/div/div")
#Detail S2 Cards
page_section(:detail_red_card, DetailRedCard, xpath: "/html/body/app-component/app-page/div[2]/div/div/div[1]/div/div/div/ngb-tabset/div/div/red/div[1]/div/div/div")
page_section(:detail_green_card, DetailGreenCard, xpath: "/html/body/app-component/app-page/div[2]/div/div/div[1]/div/div/div/ngb-tabset/div/div/green/div[1]/div/div/div")
page_section(:detail_yellow_card, DetailYellowCard, xpath: "/html/body/app-component/app-page/div[2]/div/div/div[1]/div/div/div/ngb-tabset/div/div/yellow/div[1]/div/div/div")
end
EDIT2: Adding page_section content per request. All Option Cards share these elements at a minimum. Different elements in the Detail Cards but same structure as Option Cards.
class OptionRedCard
include PageObject
def field1_limit
text_field_element(xpath: "/html/body/app-component/app-page/div[2]/div/div/div[1]/div/div/div/ngb-tabset/div/div/red-unit/div[2]/div[2]/div/div/div/red/form/div/div/div/table/tbody/tr[2]/td[2]/div/div[1]/div/currency/div/input")
end
def field1_agg
text_field_element(xpath: "/html/body/app-component/app-page/div[2]/div/div/div[1]/div/div/div/ngb-tabset/div/div/red-unit/div[2]/div[2]/div/div/div/red/form/div/div/div/table/tbody/tr[2]/td[2]/div/div[2]/div/currency/div/input")
end
def field2_limit
text_field_element(xpath: "/html/body/app-component/app-page/div[2]/div/div/div[1]/div/div/div/ngb-tabset/div/div/red-unit/div[2]/div[2]/div/div/div/red/form/div/div/div/table/tbody/tr[3]/td[2]/div/div[1]/div/currency/div/input")
end
def field2_agg
text_field_element(xpath: "/html/body/app-component/app-page/div[2]/div/div/div[1]/div/div/div/ngb-tabset/div/div/red-unit/div[2]/div[2]/div/div/div/red/form/div/div/div/table/tbody/tr[3]/td[2]/div/div[2]/div/currency/div/input")
end
def field3_limit
text_field_element(xpath: "/html/body/app-component/app-page/div[2]/div/div/div[1]/div/div/div/ngb-tabset/div/div/red-unit/div[2]/div[2]/div/div/div/red/form/div/div/div/table/tbody/tr[4]/td[2]/div/div[1]/div/currency/div/input")
end
def field3_agg
text_field_element(xpath: "/html/body/app-component/app-page/div[2]/div/div/div[1]/div/div/div/ngb-tabset/div/div/red-unit/div[2]/div[2]/div/div/div/red/form/div/div/div/table/tbody/tr[4]/td[2]/div/div[2]/div/currency/div/input")
end
def field1_agg_value
field1_agg.attribute_value('data-value')
end
def field2_agg_value
field2_agg.attribute_value('data-value')
end
def field3_agg_value
field3_agg.attribute_value('data-value')
end
end
I think the short answer to your question, is no, there is no built-in support for passing a value to the page sections. However, here are some alternatives I can think of.
Option 1 - Use initialize_accessors
Usually the accessors are executed at compile time. However, you could use the #initialize_accessors method to defer the execution until the initialization of the page object (or section). This would let you define your accessors in a base class that, at initialization, inserts color type into the paths:
class BaseCard
include PageObject
def initialize_accessors
# Accessors defined with placeholder for the color type
self.class.text_field(:field1_limit, xpath: "/html/body/some/path/#{color_type}/more/path/input")
end
end
# Each card class would define its color for substitution into the accessors
class OptionRedCard < BaseCard
def color_type
'red'
end
end
class OptionGreenCard < BaseCard
def color_type
'green'
end
end
class BasePO
include PageObject
page_section(:options_red_card, OptionRedCard, xpath: '/html/body/path')
page_section(:options_green_card, OptionGreenCard, xpath: '/html/body/path')
end
Option 2 - Using relative paths
My suggested approach would be to use relative paths such that the color can be removed from the path of the page section. From the objects provided, you might be able to do something like:
class OptionCard
include PageObject
element(:unit) { following_sibling(tag_name: "#{root.tag_name}-unit") }
div(:field1_limit) { unit_element.tr(index: 1).text_field(index: 0) }
div(:field1_agg) { unit_element.tr(index: 1).text_field(index: 1) }
div(:field2_limit) { unit_element.tr(index: 2).text_field(index: 0) }
div(:field2_agg) { unit_element.tr(index: 2).text_field(index: 1) }
end
class BasePO
include PageObject
# Page sections only defined to the top most element of the section (the color element)
page_section(:options_red_card, OptionCard, xpath: "/html/body/app-component/app-page/div[2]/div/div/div[1]/div/div/div/ngb-tabset/div/div/red")
page_section(:options_green_card, OptionCard, xpath: "/html/body/app-component/app-page/div[2]/div/div/div[1]/div/div/div/ngb-tabset/div/div/green")
end
I have an RSS feed that I am writing an RSpec test for. I want to test that the XML document has the correct nodes and structure. Unfortunately, I can't find any good examples of how to do this in a clean way. I have only found some half-implemented solutions and outdated blog posts. How can I test the structure of an XML document using RSpec?
Hi I can recommend you to use custom matcher for this.
require 'nokogiri'
RSpec::Matchers.define :have_xml do |xpath, text|
match do |body|
doc = Nokogiri::XML::Document.parse(body)
nodes = doc.xpath(xpath)
nodes.empty?.should be_false
if text
nodes.each do |node|
node.content.should == text
end
end
true
end
failure_message_for_should do |body|
"expected to find xml tag #{xpath} in:\n#{body}"
end
failure_message_for_should_not do |response|
"expected not to find xml tag #{xpath} in:\n#{body}"
end
description do
"have xml tag #{xpath}"
end
end
Full example can be found here
https://gist.github.com/Fivell/8025849
No longer necessary to roll your own. We deal this problem daily, using the equivalent-xml matcher at https://github.com/mbklein/equivalent-xml .
require 'rspec/matchers'
require 'equivalent-xml'
...
expect(node_1).to be_equivalent_to(node_2)
Has options for edge cases like whitespace-preservation.
Your other option is to use a formal XSD template for strict validation.
context 'POST #join' do
it 'does successfully hit join xml route' do
post :join,
format: :xml
response.content_type.should == "application/xml"
response.should be_ok
end
end
This worked for me. I didn't realize I had to pass format: :xml. My join route responds to /join.xml and I was testing that this was successful.
Give Approvals a try, it works with rspec, I have used for testing Json payload, and it is used with Minitest in exercism.io
EDIT
it "returns available traffic information around me" do
post '/search_traffic_around', {location: [-87.688219, 41.941149]}.to_json
output = last_response.body
options = {format: :json, name: 'traffic_around_location'}
Approvals.verify(output,options)
end
the JSON I am verifying against is located in spec/fixtures folder named traffic_around_location.approved.json
Implementation where the above snippet is pulled from is available here
How it works is you supply it an expected Payload, JSON, XML, TXT and HTML this I am sure it supports in spec/fixtures and when you run the test it checks to confirm that the payload received matches the expected(approved) payload the test would pass if it matches else the test fails
def scrape!(url)
Anemone.crawl(url) do |anemone|
anemone.on_pages_like %[/events/detail/.*] do |page|
show = {
headliner: page.doc.at_css('h1.summary').text,
openers: page.doc.at_css('.details h2').text
}
puts show
end
end
end
Writing a scraper in Anemone, which uses Nokogiri under the hood..
Sometime the selector .details h2'returns nothing because its not in the HTML, and calling text on it throws an exception.
I'd like to avoid if/elses all over the place...
if page.doc.at_css('.details h2').empty?
openers: page.doc.at_css('.details h2').text
end
Is there any more eloquent way of handling errors produced by inconsistant mark up? For instance CoffeeScript has the existentional operator person.name?.first(). If the HTML has the element, great make the object and call text on it. If not, move on and dont add it to the hash.
You just need do:
anemone.on_pages_like %[/events/detail/.*] do |page|
if not page.nil?
...#your code
end
end
I wonder if there's any good way to reuse data between implementation and description of a spec... More particularly, I'd like to be able do something like the following:
describe "#some_method" do
let(:arg1) { "Sample String 1" }
let(:arg2) { "Sample String 2" }
context "with '#{arg1}', its result" do
specify { some_method(arg1).should == 1 }
end
context "with '#{arg2}', its result" do
specify { some_method(arg2).should == 2 }
end
end
Of course, this code won't work - arg1 and arg2 are not accessible outside of spec bodies.
Is it possible to achieve the similar result without using global variables or external classes?
Update:
I'm interested in the output of the spec. Something like this:
#some_method
with 'Sample String 1' its result
should == 1
with 'Sample String 2' its result
should == 2
The answer is that you don't use dynamic descriptions. The RSpec way to do this would be
describe "#some_method" do
it "extracts the number correctly" do
some_method("Sample String 1").should == 1
some_method("Sample String 2").should == 2
end
end
It is no problem to hard-code test data in your specs. If you want more complete output, you can use a custom matcher
require 'rspec'
class Test
def some_method(str)
str[/[0-9]+/].to_i
end
end
RSpec::Matchers.define :return_value_for_argument do |result, arg|
match do |actual|
actual.call(arg) == result
end
description do
"return #{result.inspect} for argument #{arg.inspect}"
end
end
describe Test do
let(:test) { Test.new }
describe "#some_method" do
subject { test.method(:some_method) }
it { should return_value_for_argument 1, "str 1" }
end
end
When doing API testing, I find it incredibly useful to be able to see the path, params, and response of each test. I have used the very useful tips given by Jeff Nyman to store things in the example.metatadata[:thing_i_want_to_store_like_url] of each test and with a custom formatter, print it out.
So my tests output look something like this:
that jonathan does not know it exists
:path : /user/20
:params: {}
=> response: {"error"=>{"message"=>"error", "code"=>404}}
that jonathan cannot edit
:path : /user/20/update
:params: {:name=>"evil_name"}
=> response: {"error"=>{"message"=>"error", "code"=>404}}
It's not appropriate to cite specific arguments in your descriptions. Your descriptions should provide a human-readable description of the desired behavior, without reference to specific arguments in most cases.
I'm currently testing my mailers with RSpec, but I've started setting up multipart emails as described in the Rails Guides here: http://guides.rubyonrails.org/action_mailer_basics.html#sending-multipart-emails
I have both mailer templates in text and html formats, but it looks like my tests are only checking the HTML portion. Is there a way to check the text template separately?
Is it only checking the HTML view because it's first in the default order?
To supplement, nilmethod's excellent answer, you can clean up your specs by testing both text and html versions using a shared example group:
spec_helper.rb
def get_message_part (mail, content_type)
mail.body.parts.find { |p| p.content_type.match content_type }.body.raw_source
end
shared_examples_for "multipart email" do
it "generates a multipart message (plain text and html)" do
mail.body.parts.length.should eq(2)
mail.body.parts.collect(&:content_type).should == ["text/plain; charset=UTF-8", "text/html; charset=UTF-8"]
end
end
your_email_spec.rb
let(:mail) { YourMailer.action }
shared_examples_for "your email content" do
it "has some content" do
part.should include("the content")
end
end
it_behaves_like "multipart email"
describe "text version" do
it_behaves_like "your email content" do
let(:part) { get_message_part(mail, /plain/) }
end
end
describe "html version" do
it_behaves_like "your email content" do
let(:part) { get_message_part(mail, /html/) }
end
end
This can be tested with regular expressions.
Finding things in the HTML portion (use #should after this to match):
mail.body.parts.find {|p| p.content_type.match /html/}.body.raw_source
Finding things in the plain text portion (use #should after this to match):
mail.body.parts.find {|p| p.content_type.match /plain/}.body.raw_source
Checking that it is, indeed, generating a multipart message:
it "generates a multipart message (plain text and html)" do
mail.body.parts.length.should == 2
mail.body.parts.collect(&:content_type).should == ["text/html; charset=UTF-8", "text/plain; charset=UTF-8"]
end
To make things even simpler, you can use
message.text_part and
message.html_part
to find the respective parts. This works even for structured multipart/alternative messages with attachments. (Tested on Ruby 1.9.3 with Rails 3.0.14.)
These methods employ some kind of heuristic to find the respective message parts, so if your message has multiple text parts (e.g. as Apple Mail creates them) it might fail to do the "right thing".
This would change the above method to
def body_should_match_regex(mail, regex)
if mail.multipart?
["text", "html"].each do |part|
mail.send("#{part}_part").body.raw_source.should match(regex)
end
else
mail.body.raw_source.should match(regex)
end
end
which works for both plaintext (non-multipart) messages and multipart messages and tests all message bodies against a specific regular expression.
Now, any volunteers to make a "real" RSpec matcher out of this? :) Something like
#mail.bodies_should_match /foobar/
would be a lot nicer ...
If your email has attachments the text and html parts will end be placed in a multipart/alternative part. This is noted on under Sending Emails with Attachments in the Rails 3 Guide.
To handle this, I first simplified the get_message_part method above to:
def get_message_part(mail, content_type)
mail.body.parts.find { |p| p.content_type.match content_type }
end
Then in my test:
multipart = get_message_part(email, /multipart/)
html = get_message_part(multipart, /html/)
html_body = html.body.raw_source
assert_match 'some string', html_body
I have done this way, I found it simpler since the content of both emails is gonna be similar except styles and markup.
context 'When there are no devices' do
it 'makes sure both HTML and text version emails are sent' do
expect(mail.body.parts.count).to eq(2)
# You can even make sure the types of the part are `html` and `text`
end
it 'does not list any lockboxes to be removed in both types emails' do
mail.body.parts.each do |part|
expect(part.body).to include('No devices to remove')
end
end
end