I ran just the specs with chrome 38 and I noticed that there are failing specs for #select and #select_value where multiple selections are expected. These tests weren't failing for me last week, I'm not sure what might have changed other than browser version.

WebDriver exposes #maximize method for window but it's not used anywhere in Watir.

Something like this:

browser.window.maximize

Perhaps to_s should be rewritten to return nicer / more predictable output across impls.

I'm closing #63, and adding this issue as a placeholder to properly update the watirspecs to ensure the proper functioning of all permutations of nested elements, frames, and their collections.

Currently, we serve HTML from the local file system (using file:// URLs) wherever we can to reduce the overhead of going through the server. However, if we want to run watirspec on mobile devices, we'll need to use the server for everything.

This should be an optional flag that can be set in e.g. implementation.rb

maybe I'm just not looking in the right place, but I can't find anything for what .to_a is supposed to do when used against an OptionCollection object. I see it in the rspec but nothing under the spec for collections or select_list.. is it hiding somewhere else?

is this going to return just the text, or an array of hashes or what?

Specs for opening/closing the browser should be able to do this without affecting other specs (i.e. the global browser instance).

With most browsers, those specs can just open and close a separate instance, but this isn't possible with IE where only one browser instance is allowed. So watirspec should provide a way of dealing with this. Perhaps:

in_separate_browser do |b|
  ...
end

The method will then take care of preparing the global browser instance for further use after yielding.

Running the watirspec tests generates a lot of noise:

[2012-02-02 16:12:54] INFO  WEBrick 1.3.1
[2012-02-02 16:12:54] INFO  ruby 1.8.7 (2011-06-30) [i386-mingw32]
[2012-02-02 16:12:54] INFO  WEBrick::HTTPServer#start: pid=3128 port=2001
running watirspec against Watir::IE
.............localhost - - [02/Feb/2012:16:13:02 Pacific Standard Time] "GET /plain_text HTTP/1.1" 200 18
- -> /plain_text
........localhost - - [02/Feb/2012:16:13:05 Pacific Standard Time] "GET /non_control_elements.html HTTP/1.1" 304 0
- -> /non_control_elements.html
localhost - - [02/Feb/2012:16:13:05 Pacific Standard Time] "GET /javascript/helpers.js HTTP/1.1" 304 0
http://localhost:2001/non_control_elements.html -> /javascript/helpers.js

When all I really want to see is this:

running watirspec against Watir::IE
.....................

There is no way, at least no obvious way, to turn off all of the noise from web server logging. I've tried inserting "set :logging, false" alongside the other set commands in lib/server.rb, but that has no effect.

I hope this isn't some dumb thing I'm overlooking. :-)

A lot of duplication can be removed by using RSpec's shared examples.

It should be possible to specify deviates_on_guards to take into account WebDriver browser implementations for allowing to create different specs for browsers which do something differently.

I stated at the Bazaar that I'd like to see this repo merged in with the existing WebDriver code, since that is the only code base that is currently testable by this repo. The point was made that we'd like Watir to have options to be extensible by code in other repos, which could only be tested if Watirspec remained separate.

I propose:

1. Remove guards for :watir_classic
2. Remove need to specify :webdriver in guards
3. Move current watir-webdriver repo specs into watirspec so that all tests currently applicable to watir are in one place.

I'd also love to see Watir & Ruby Selenium specs run with the same test implementations (same setup, same server implementation and guard structures, etc), but we can talk about that possibility later.

Since we can't fork() on windows, the server is now running in a Ruby thread, which works fine on JRuby but might cause problems on MRI (at least < 1.9). Probably better to start a new ruby process using Process.create from win32-process.

Having a #to_hash method on definition lists seems like a useful addition - e.g.

<dl>
      <dt>Address</dt>
      <dd>Foo Bar</dd>

      <dt>City</dt>
      <dd>New York</dd>
</dl>

browser.dl.to_hash 
=> {"Address" => "Foo Bar", "City" => "New York"}

Are there other elements that people commonly turn into a Ruby data structure? We already have Table#hashes.

While running watirspec with Chrome, toward the end of the run, everything starts giving this error.

It isn't always starting on the same test, and it isn't always the same wire call. I haven't had any issues with Firefox. Is this a Chrome bug? (I think my system just updated Chrome today). Any ideas what I can do to fix this, regardless?

Errno::EADDRNOTAVAIL: Cannot assign requested address - connect(2) for "127.0.0.1" port 9516
/home/titus/.rvm/rubies/ruby-2.2.0/lib/ruby/2.2.0/net/http.rb:879:in initialize' /home/titus/.rvm/rubies/ruby-2.2.0/lib/ruby/2.2.0/net/http.rb:879:inopen'
/home/titus/.rvm/rubies/ruby-2.2.0/lib/ruby/2.2.0/net/http.rb:879:in block in connect' /home/titus/.rvm/rubies/ruby-2.2.0/lib/ruby/2.2.0/timeout.rb:74:intimeout'
/home/titus/.rvm/rubies/ruby-2.2.0/lib/ruby/2.2.0/net/http.rb:878:in connect' /home/titus/.rvm/rubies/ruby-2.2.0/lib/ruby/2.2.0/net/http.rb:863:indo_start'
/home/titus/.rvm/rubies/ruby-2.2.0/lib/ruby/2.2.0/net/http.rb:852:in `start'

The watir2 branch should have specs for using selectors with the plural methods, which is already implemented in watir-webdriver:

browser.divs(:class => "foo") #=> Watir::DivCollection

Since different browsers will return different page sources for the same page, this spec should be less strict.

Celerity could easily use JS alert() calls to verify event handling, but this usually blocks on other implementations.

The specs expect to be able to reference e.g. Watir::Exception::UnknownObjectException as just UnknownObjectException. This is done by including Watir::Exception in the top level object, and frequently leads to NameErrors that pop up in the real world but not in the specs.

We should either (a) fix the specs to reference the full exception name, or (b) only include the Exception module in the specs, not the top level object.