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
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
* 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
* We might end up focusing more on the integration than developing new
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.
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
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!
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.
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>
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.
+1 on the merge if the Capybara codebase is going to be the starting
-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
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.
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:
+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.
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
πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
[The fox knows many things, but the hedgehog knows one big thing.]
Archilochus, Greek poet (c. 680 BC – c. 645 BC)
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.
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.
My 2 cents..
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
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
Which tests? I think you are confusing capybara with cucumber.
Capybara doesn't have .feature files.