New step for validating definition lists about spreewald HOT 7 CLOSED

This is how I check long definition lists in tests:

Then I should see in this order:
  """
  Campaign
  Product 2000

  Client
  OmniCorp

  Targeting
  Untargeted

  ProDia ID
  PD12345

  Booked period
  01.04.2017 12:00 - 01.04.2017 12:12 (12m)

  Display duration
  101 seconds

  Target URL
  http://example.com/button
  """

I would not like to use 7 steps for this, since the actual expected values would get lost in the noise.

from spreewald.

For your example I would suggest Then I should see "Name Marcel White". The Then I should see step ignores the tags between Name and Marcel White. This way it will also not be matching your heading.
In my opinion, working with classes seems a good way to solve ambiguity as well, e.g. with a class user--attributes on the dl-tag: Then I should see "Name Marcel White" within the user's attributes (you maybe need to enhance the selectors.rb to make it work with "the user's attributes").

from spreewald.

I'm not sure if this step is generic and often-used enough to be added to Spreewald. I have never needed it.

If we'll add it anyway, I think we should not require exact matches, as this offers little flexibility and might break on whitespace in the HTML. Could we just filter by the plain text?

from spreewald.

I'm not sure if this step is generic and often-used enough to be added to Spreewald. I have never needed it.

The step results of a show view, which used description lists to pair the names and the values of an instance. I saw this pattern in some projects.

Often people use a combination of the Then I should be on the... and And I should see... steps. For me this test is often too weak: E.g. you have a user with a name attribute. Then an example sow view could look like this:

<h1>Marcel White</h1>
<dl>
  <dt>Name</dt>
  <dd>Marcel White</dd>
<dl>

This test will be green, even the description list is missing.

If we'll add it anyway, I think we should not require exact matches, as this offers little flexibility and might break on whitespace in the HTML. Could we just filter by the plain text?

If you have terms like "Name" and "Short Name", not exact matches for terms will result ambiguous matches. For the description you are right, it might be too strict.

Another approach is to use classes to be more exact, but for description lists I'm not sure how to solve this best, as I need to wrap the dt and dd somehow.

from spreewald.

Then I should see "Name Marcel White" is a great way!

from spreewald.

@judithroth's suggestion is a clever workaround I frequently use.

As for your step suggestion, what about:

Then /^"(.*?)" should be defined as "(.*?)"$/ do |term, description|
  term_exact_match = /\A#{Regexp.escape(term)}\z/

  patiently do
    page.
      find('dt', text: term_exact_match). # Exact match required
      find('+dd', text: description) # Partial match allowed
  end
end

from spreewald.

Below is a new step I'm currently using for testing show views that list a lot of key/value pairs.

Other than the I should see in this order step, the one below doesn't care about the order of key/value pairs. In my project the order of pairs frequently changes vertically, or they swap grid columns, and I don't want to have to adjust tests all the time:

Then /^I should see the following paragraphs in any order:$/ do |text|
  clean_lines = ->(lines) { lines.map(&:strip).reject(&:blank?) }
  parts = text.split(/\n\n/).map(&:strip).reject(&:blank?)
  parts = clean_lines[parts]
  parts.each do |part|
    lines = part.split(/\n/)
    lines = lines.map { |line| line.gsub(/\s+/, ' ')}
    lines = clean_lines[lines]
    pattern = lines.collect(&Regexp.method(:quote)).join('.*?')
    pattern = pattern.gsub('\\*', '.*?')
    pattern = Regexp.compile(pattern)
    patiently do
      expect(page).to have_text(pattern)
    end
  end

end

I'm waiting if this is useful a second time before I add it to Spreewald.

from spreewald.