ngauthier/domino

View abstraction for integration testing

domino's Issues

Change method name _ to - for class name look up

I will put some code to this, but wanted to get your thoughts on it. I know most people prefer "my-thing" class name to "my_thing". It is tedious to declare attributes in domino as the following always

attribute :first_name, ".first-name"
attribute :last_name, ".last-name"
attribute :primary_phone, ".primary-phone"

If not the default, perhaps a setting, as to remain backwards compatible.

Capybara::DSL#find overwritten by Enumerable

Capybara's find command is not available in a class method of a domino because Enumerable overrides it. I think all we have to do is include Enumerable before Capybara::DSL. Then if we need Enumerable.find we can just use Enumerable.detect.

-this.self

find_by_attribute and computed attribute values

find_by_attribute does not honor attribute conversions defined by blocks passed to the attribute method. Example

class Person < Domino
  selector "li.person"

  attribute :age do |text|
    text.to_i
  end
end

<li class="person"><span class="age">23</span></li>

Person.first.age => 23
Person.find_by_age(23) # => nil
Person.find_by_age("23") # => some person

I've pushed a failing test to the find_by_computed branch of my fork.

I'm wondering:

1. Is this a bug that should be fixed?
2. If we ever want to add find_by_age! to go along with the recently added find! method, how are we going to do it? The detect in find_by_attribute can easily be fixed to compare against the computed value, but I do not see how we can pass the ruby block to capybara to make is wait for computed values to appear.

Page-Object model integration

This is the closest thing that came to an idea I had for a testing framework. Dominos is a good metaphor to visualize it.

We had a 30+ page deep application for insurance agents to get quotes, not your Amazon style 3 clicks gets you anywhere. We could easily map the tests to the pages with the page object model. The flows between pages however were a beast, and too much behavior was hard coded into the page object instead of being consumed from a test configuration file.

I want a testing framework that asks two simple questions when defining flows, we could call these the domino questions.

1. What page object did you come from?
2. What actions did you do on that page to get to this page?

Your framework is close, but not quite there. Also, you need a serialized format for things like click actions so they can be read as data, not hard-coded in Capybara.

Fix 1.8 Compatibility

API Inconsistency: find! vs find_by!

Hi,

I just noticed the addition of the find_by! method in #19. From my point of view, this introduces an unfortunate semantic inconsistency with the find! method added earlier in #14.

When using a JS Capybara driver:

• find! waits for elements to appear
• find_by! simply raises an exception if the element is not already on the page

As mentioned in #15, I am not sure how the waiting behavior could be added to find_by! in the presence of computed attributes. As a last resort one could consider renaming find! to something like await. Still this would require a breaking API change.

Domino each does not respect default_wait_time

The issue is if you do something that affects the DOM immediately prior to calling each or all on a Domino class it will return an empty array.

I believe if you change https://github.com/ngauthier/domino/blob/master/lib/domino.rb#L124 to use find instead it should work. I'm not exactly sure how to make the test fail.