Possible merge with Webrat?

237 views
Skip to first unread message

jnicklas

unread,
Feb 5, 2010, 6:12:56 PM2/5/10
to Capybara
I just talked with Bryan Helmkamp, the creator and maintainer of
Webrat. We were discussing a possible merge of Capybara and Webrat in
the tradition of the RSpec/Micronaut and Rails/Merb merges. I'd like
to hear peoples oppinions if you think this is a good or bad idea. The
exact details of the merge are as yet unclear, but the idea is for
Webrat to adopt the functionality currently provided by Capybara, such
as the rack server and the support for different drivers.

There'll probably be separate gems for the different drivers (selenium/
webdriver, culerity, etc...). We haven't decided which codebase this
work would start with. I personally would like to base this on
Capybara of course, we'll have to see which looks to be the easier
path.

As I see it, merging with Webrat has some huge advantages:

* Webrat has a huge community behind it. We've had a surprisingly
active community behind Capybara and we've accomplished a lot. With
even more hands we could build something that's even more kick-ass.

* Smoother upgrade path for both Webrat and Capybara users. We'll be
working at making the upgrade process as smooth as possible, that way
we can hopefully upgrade most existing Webrat users to run on the new
merged version.

* Bryan is very positive about breaking compatibility in the few
places where it matters. This is most importantly Rails < 2.3
compatibility. So we have the opportunity to introduce the fantastic
things we've done on Capybara to a wider audience.

The disadvantages as I see them could be:

* Capybara has had a high pace and an active community, we risk
slowing that down.

* We risk having to take on some of the legacy cruft that's in the
Webrat codebase. Bryan has been very adamant that he's keen on
trimming the fat in Webrat though, so I'm not too worried about this
one.

* We might end up focusing more on the integration than developing new
features.

I'd like to emphasise that this is not a done deal, as a member of the
Merb community back then, I was disappointed by the fact that the
community was never asked about the merge. So please weigh in with
your oppinions on this.

/Jonas

Jason Huggins

unread,
Feb 5, 2010, 6:30:47 PM2/5/10
to ruby-c...@googlegroups.com
Let me know if you need help from the Selenium devs. I can't promise
*I'd* do the work myself, but I do have a bully pulpit. :-)

-jason huggins
http://saucelabs.com

Rodrigo Rosenfeld Rosas

unread,
Feb 5, 2010, 6:33:13 PM2/5/10
to ruby-c...@googlegroups.com
Hi Jonas,

Webrat introduced a great API which inspired Capybara one's.

Both have basically the same goals. I don't see why not merging, actually.

Having multiple drivers (selenium, webdriver, htmlunit, etc) support
would be awesome!

If you are OK working together, I think this will be a great merge. I
understand why you started a new project instead of contributing to
webrat. It is much easier to test new ideas. Once they proved valid and
also proved your talent, I don't know why Bryan would be hesitant about
sharing commit access with you so that both frameworks could concentrate
efforts in making a better framework, improving performance and support
for Javascript.

Not only you two would become more productive together but both
comunities could join to contribute with code faster...

So, why not?

Thanks for talking about this merge with Bryan!

Best regards,

Rodrigo.

Bryan Helmkamp

unread,
Feb 5, 2010, 6:24:18 PM2/5/10
to Capybara
Just wanted to chime in a bit on this conversation...

I've been really happy with the things I've been seeing in Capybara. I
raised the idea of a merge with Jonas because I think working together
we could produce an even better, more polished tool for everyone (and
ourselves!) to use.

I think the implementation core of Capybara is really good, and would
be an excellent base of a #1 most awesome Ruby web integration testing
tool. I'm especially happy that we would be providing a smooth upgrade
path so the existing Webrat users can upgrade if they choose.

Happy to answer any questions people have that I can.

Cheers,

-Bryan

Rick DeNatale

unread,
Feb 5, 2010, 6:50:20 PM2/5/10
to ruby-c...@googlegroups.com

I'm all for it, as long as you don't pick a name that's even longer
and harder to spell.

How about Caprat!

Also what better time to discuss a merger than the day of the beta
release of Rails 3.

Now, how about a group hug! <G>
--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

Aslak Hellesøy

unread,
Feb 5, 2010, 6:49:56 PM2/5/10
to ruby-c...@googlegroups.com, Capybara

Den 6. feb. 2010 kl. 00.24 skrev Bryan Helmkamp <br...@brynary.com>:

> Just wanted to chime in a bit on this conversation...
>
> I've been really happy with the things I've been seeing in Capybara. I
> raised the idea of a merge with Jonas because I think working together
> we could produce an even better, more polished tool for everyone (and
> ourselves!) to use.
>
> I think the implementation core of Capybara is really good, and would
> be an excellent base of a #1 most awesome Ruby web integration testing
> tool. I'm especially happy that we would be providing a smooth upgrade
> path so the existing Webrat users can upgrade if they choose.
>

Great news Bryan and Jonas. This will be great.

Aslak

Wincent Colaiuta

unread,
Feb 5, 2010, 7:18:37 PM2/5/10
to Capybara
On 6 feb, 00:12, jnicklas <jonas.nick...@gmail.com> wrote:
> I just talked with Bryan Helmkamp, the creator and maintainer of
> Webrat. We were discussing a possible merge of Capybara and Webrat in
> the tradition of the RSpec/Micronaut and Rails/Merb merges. I'd like
> to hear peoples oppinions if you think this is a good or bad idea. The
> exact details of the merge are as yet unclear, but the idea is for
> Webrat to adopt the functionality currently provided by Capybara, such
> as the rack server and the support for different drivers.

+1 on the merge if the Capybara codebase is going to be the starting
point.

-1 if Webrat is going to be the basis.

One of the reasons switched to Capybara so quickly after it was
announced was because I was so impressed with the cleanness of the
code and the fact that everything just worked out of the box so
brilliantly.

For me that is _the_ thing which Capybara brings to the table, and if
it got merged _into_ another codebase it would lose that edge.

Cheers,
Wincent

Hedgehog

unread,
Feb 5, 2010, 8:13:26 PM2/5/10
to Capybara

On Feb 6, 10:12 am, jnicklas <jonas.nick...@gmail.com> wrote:
> I just talked with Bryan Helmkamp, the creator and maintainer of
> Webrat. We were discussing a possible merge of Capybara and Webrat in
> the tradition of the RSpec/Micronaut and Rails/Merb merges. I'd like
> to hear peoples oppinions if you think this is a good or bad idea. The
> exact details of the merge are as yet unclear, but the idea is for
> Webrat to adopt the functionality currently provided by Capybara, such
> as the rack server and the support for different drivers.

I'm relatively new to web testing, and have only been a webrat user,
so please read the following with that in mind.

The mention of 'rack server' has me intrigued and nervous.
If this involves building in use of Rack::Test, then please could
thought be given to not doing so?
I tried to write some specs for async_sinatra, I was able to do so
after much wrestling with Rack::Test, a quote from a post I made to
the Sinatra list:

" I did get to exercise async_sinatra Rack::Test.
crohr has also done this with Async2Sync. Although was able to
(eventually) spec some asyn behavior it wasn't a nice experience, and
I quite possibly ended up reimplementing somthing crohr has.
Via a discussion on irc, I think with raggi, I would agree that
whetever is being spec'd with Rack::Test probably isn't what I will be
running in production. I'm not saying doesn't have a role just I have
found, (see the previous posts) Using Rack::Test /can/ lead you:
a) develop (figuratively) incorrect exceptations, b) write/code
expectations that can't be met once you take out Rack::Test."

As part of another project I'm currently off shaving some Yak, so
haven't managed to complet my async spec expedition.
For what it is worth I decided that the approach to explore next was
along the lines set out by Chris Tierney here:

http://dynamicorange.com/2009/02/18/ruby-mock-web-server/comment-page-1/

my $0.02

Luke Melia

unread,
Feb 5, 2010, 7:29:54 PM2/5/10
to Capybara
I'm a contributor to Webrat, and wrote some of the original selenium
code (that many of you have probably cursed at one point or another).
The selenium support started as an experiment and I'm happy to see
Capybara has taken a fresh look at the problem and produced a cleaner
implementation of the concepts.

+1 to a merge with Capybara. I'm confident that Jonas and Bryan and
the community will produce a high-quality library.

I do think webrat has the better name.

Cheers,
Luke

Jonas Nicklas

unread,
Feb 5, 2010, 8:29:50 PM2/5/10
to ruby-c...@googlegroups.com
The comment about the "rack server" wasn't about rack-test, but rather
Capybara's ability to run any rack app automatically, so if give
Capybara a rack app, it will automatically boot up, no fiddling with
script/server and the like.

That being said, Capybara does use rack-test, with very good results
so far. There've been comparatively few bug reports about the
rack-test driver, and it's worked fine for every project I've tried it
on. If there's a similarly stable/mature alternative out there that
handles async requests better, I'd love to know about it.

/Jonas

Hedge Hog

unread,
Feb 5, 2010, 8:48:33 PM2/5/10
to ruby-c...@googlegroups.com
On Sat, Feb 6, 2010 at 12:29 PM, Jonas Nicklas <jonas....@gmail.com> wrote:
> The comment about the "rack server" wasn't about rack-test, but rather
> Capybara's ability to run any rack app automatically, so if give
> Capybara a rack app, it will automatically boot up, no fiddling with
> script/server and the like.
>
> That being said, Capybara does use rack-test, with very good results
> so far. There've been comparatively few bug reports about the
> rack-test driver, and it's worked fine for every project I've tried it
> on. If there's a similarly stable/mature alternative out there that
> handles async requests better, I'd love to know about it.
>

Just for the record, I am not aware of any rack-test alternative
driver, nevermind a stable/mature one :)
The only alternative I could think of was to fire up a mock server as
outlined in the weblog I cited.
The idea, if realisable, would be to run specs etc. against the code
and server you'd encounter in production.
Of course these difficulties may be specific to async settings, but I
thought these experiences, and possible alternative, were worth
mentioning.

Regards

--
πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
[The fox knows many things, but the hedgehog knows one big thing.]
Archilochus, Greek poet (c. 680 BC – c. 645 BC)
http://wiki.hedgehogshiatus.com

Matt Wynne

unread,
Feb 6, 2010, 8:07:58 AM2/6/10
to Capybara
I'm right behind this. Hats off to the webrat guys for acknowledging
the quality of the capybara code.

I suggest you keep the webrat name (which is already well known) and
the capybara code.

I wouldn't worry too much about the upgrade path / backwards
compatibility if it means compromising the lean-ness of the codebase.

Joaquin Rivera Padron

unread,
Feb 9, 2010, 7:26:06 AM2/9/10
to ruby-c...@googlegroups.com
+ 1 here

great news

joaquin

2010/2/6 Matt Wynne <matt....@gmail.com>



--
www.least-significant-bit.com

mr.gaffo

unread,
Feb 9, 2010, 5:43:18 PM2/9/10
to Capybara
I haven't looked at the Capybara codebase yet but I think it's a good
idea. As a contributor to webrat I know that there are major parts of
it that aren't well tested and are very crufty. Capybara, being much
younger likely doesn't have that cruft, but I'll take a look and make
sure.

I think the webrat name is better as it has more google notice and if
they merge they should stay under Webrat even if the code is 100%
Capybara :) Also I keep having to look at my title to spell Capybara.

With the matchers that Cucumber provides, I think the majority of our
users wouldn't even notice the changeover.

-Mike

Sam Goldstein

unread,
Feb 9, 2010, 10:09:13 PM2/9/10
to ruby-c...@googlegroups.com
+1

Elliot Winkler

unread,
Feb 14, 2010, 6:37:03 PM2/14/10
to Capybara
I just want to say I am totally for this idea. I haven't gotten a
chance to play with Capybara that much yet but just having spent a lot
of time with Webrat and Culerity, when I heard about Capybara I was
relieved because a common (and better) API has been sooo needed. I
like the direction Capybara is going, and since Capybara was inspired
by Webrat I think it makes total sense to combine the two.

Steven Parkes

unread,
Feb 24, 2010, 12:25:36 AM2/24/10
to ruby-c...@googlegroups.com
+1

Lenny Marks

unread,
Feb 24, 2010, 12:08:50 PM2/24/10
to ruby-c...@googlegroups.com
I'm not opposed, but just a little concerned.. I admit, I haven't
looked at Webrat in quite some time but I had tried way back when
Selenium integration was just going in. I was attracted to the idea of
not having to write steps using two entirely different DSLs depending
on whether they needed javascript or not. I eventually abandoned it
for just that. My impression(and this may not be true now) was that
Webrat was too coupled with Rails integration style testing and trying
to adapt it to something like Celerity or Selenium was too much of a
gap. Capybara had the benefit of being designed from the ground up
with compatibility in mind. I like that Capybara is rather small and
simple. When speaking of learning it, I've often compared it with Haml
because its not overwhelming. A quick scan of a short wiki page pretty
much gets you going. I also found it very easy to grok the code and
contribute too. That being said, I can appreciate that it would be
nice to have one go to tool.

My 2 cents..

-lenny

RyanK

unread,
Feb 24, 2010, 11:10:09 PM2/24/10
to Capybara
I also moved from Webrat to Capybara and was pleased with how things
improved in my testing. Bringing over functionality that is missing
from Capy seems a good plan, but I'm not sure how you'd best
orchestrate a merge.

Consolidation in testing seems a good idea. I support anything that
makes the cooperation between projects easier and better so that going
from not testing at all to a full testing software stack is
straightforward.

~Ryan

Johnathon Wright

unread,
Feb 26, 2010, 12:40:52 PM2/26/10
to Capybara
+1 to the merger
+1 to branching from the capybara codebase
+1 to backward compatibility

<soapbox>
I know it makes me an oddball, but while you're retooling, please
consider moving the default location to /test/web or /test/something.
It just seems odd to have tests that aren't in the test directory.
It's not like test/unit is going to try to run a file that ends
with .feature
</soapbox>

Rob Holland

unread,
Feb 26, 2010, 12:45:48 PM2/26/10
to ruby-c...@googlegroups.com
On Fri, Feb 26, 2010 at 5:40 PM, Johnathon Wright <j...@mustmodify.com> wrote:
> +1 to the merger
> +1 to branching from the capybara codebase
> +1 to backward compatibility
>
> <soapbox>
> I know it makes me an oddball, but while you're retooling, please
> consider moving the default location to /test/web or /test/something.
> It just seems odd to have tests that aren't in the test directory.
> It's not like test/unit is going to try to run a file that ends
> with .feature
> </soapbox>

Which tests? I think you are confusing capybara with cucumber.
Capybara doesn't have .feature files.

Johnathon Wright

unread,
Feb 26, 2010, 7:48:52 PM2/26/10
to Capybara

> Which tests? I think you are confusing capybara with cucumber.
> Capybara doesn't have .feature files.

Blah. message.find_by_xpath('//soapbox').delete!

Reply all
Reply to author
Forward
0 new messages