Aslak hellesoy wrote:
> I just whipped up a little example and some doco about how to (and
> why) use RSpec with Watir. It's in RSpec's subversion under
> trunk/vendor/watir
> http://rubyforge.org/scm/?group_id=797
> http://rubyforge.org/plugins/scmsvn/viewcvs.php/trunk/vendor/watir/?root=rspec
>
> Please take a look and give some feedback. I'd like to put this up on
> RSpec's web page soon.
>
First of all, i had a hell of time figuring out how to look at these
files on Rubyforge's pages. I was never quite sure if i was looking at
the files or the commit logs.
So, for the benefit of others who may have also been confused, i
republish the meat:
> context "Google's search page" do
>
> setup do
> @browser.goto('http://www.google.com')
> end
>
> specify "should find rspec's home page when I search for rspec" do
> @browser.text_field(:name, "q").set("rspec")
> @browser.button(:name, "btnG").click
> @browser.contains_text("rspec.rubyforge.org").should_be(true)
> end
>
> specify "should not find Ali G when I search for rspec" do
> @browser.text_field(:name, "q").set("rspec")
> @browser.button(:name, "btnG").click
> @browser.contains_text("Ali G").should_be(false)
> end
>
> end
This is an Rspec/Watir test. This is not pseudo code, but the actual,
executable code. I'm sure most subscribers can easily understand what
this does. It is a lot easier to read than test::unit, isn't it?
I've actually been using parts of Rspec as part of my Watir testsuite
for a couple months now. Now Aslak is spinning this as a test-first
framework and i have been using Rspec to help build a framework that is
mostly being used to build regression tests for already existing
software. Let me very quickly summarize my use and impressions of Rspec
in general, not really commenting on this specific proposal (sorry). I'm
going fast, so if there are questions please ask, and i will slow down.
1. Rspec is made up of three libraries: a spec framework, which replaces
test::unit, a "should" framework, which replaces test::unit::assertions,
and a mock api, which is not demonstrated in the code above.
2. I decided to use both the should framework and the mock api, but not
the spec framework.
3. I did not use the spec framework mostly just because it was
incompatable with test::unit. I already have lots of tests in test-unit,
rspec has a tool that converts them to the spec format, but this did not
work for all of them, and i've also made some of my own modifications.
Note: one of the things that i liked about rspec's spec/execution
framework is that it executes in order of definition instead of
alphabetical, like test::unit. It was shortly after i made this decision
that i create watir::testcase, which also executes in order of
definition. I really like test::unit's very many test::runners and
reporting frameworks (i.e. test::unit::report), and was not willing to
give that up. I have, however, noticed that the rspec team is quickly
growing a rich set of reporting tools around this.
4. Ever have a hard time remember the correct order of arguments after
assert? Yeah, me too. That is why the "should" commands are totally
awesome. You can use them very easily without using the rest of rspec.
How? "require 'spec'". That's all you have to do and now you can
"should" anything. Here is some real code from one of our tests:
@browser.div(:class, 'Title').text.should.equal 'List Vendors'
That is way easier to read than
assert_equal 'List Vendors', @browser.div(:class, 'Title').text
And when it fails, you'll also get an error message that is easier to
read too.
(A warning to Watir users: don't mistakenly use "should.be" instead of
"should.equal". Your tests will always fail.)
But it gets better:
@browser.link(:text, matter_no).should.exist
That replaces
assert @browser.link(:text, matter_no).exist?
The "should" command automatically knows to call the "exist?" method
(with the question mark) and that it should get a true. I also use this:
@browser.link(:text, matter_no).should.not.exist
Cool, huh?
5. I use the rspec mock api because i test-drive the development of my
testing framework and therefore have to write unit tests for my code. To
do this, you need mocks. I'm not going to dive into mock theory right
now. I will say that i thought the rspec mock api was the best around.
Also, because i'm not using the spec framework, i have to use an
"undocumented" API to create mocks. Here's an example of some mock-based
code that i used to develop a spreadsheet-data parser:
def test_dispatch
mock_fixture = Spec::Api::Mock.new 'mock_fixture'
mock_fixture.should_receive(:page).exactly(7).times
mock_fixture.should_receive(:button).exactly(16).times
mock_fixture.should_receive(:link).exactly(8).times
mock_fixture.should_receive(:_eval).exactly(10).times
@destination_methods.dispatch mock_fixture
mock_fixture.__verify
end
6. One problem with "should" -- if you use it the "assertions" won't be
counted". I know how to fix this in general (i know what hooks to call)
but i haven't looked closely at the should code enough to know where to
put it. I actually intend to find a way to make "should" mean "verify"
(which will make it no throw an exception as it currently does) and then
add "must" to do what "should" currently does -- i.e. assert (except
that these will also be counted as assertions). I do realize that these
semantics don't quite make sense in the BDD context of rspec, so i
intend to do this as a monkey patch, and beg for some interfaces to
facilitate this if necessary.
7. Since i'm loathe to give up test::unit, i'm also thinking about
adding an rspec-like interface to it, with somewhat different keywords.
Questions? By the way, thanks very much to Aslak and Dave Astels and all
the other rspec contributors. Very cool stuff.
Bret
_______________________________________________
Wtr-general mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/wtr-general
