Em 24-08-2011 04:52, Marius Mårnes Mathiesen escreveu:
On Thu, Aug 18, 2011 at 2:57 AM, Rodrigo Rosenfeld Rosas
<[email protected] <mailto:[email protected]>> wrote:
The problem is that now the integrations will take 10s more to
complete here (the other 2 completed in less than a second). But
integration tests are supposed to be slower anyway ;)
First of all: adding integration tests for this is a really good idea.
Errors tend to occur in untested code, especially where integration
with other parties is involved :-)
The problem is that the Rack driver for Capybara (which is a very
fast one) won't work for this case that relies on Javascript. So
the options I tested were using the Selenium driver as well as the
Webkit driver (I would rather prefer to use the Webkit though).
So, I would like to ask help for making the "rots" OpenID test
server run (fast if possible) from a "setup" block if it's not
already running for easying the full test procedure.
If this integration test is accepted in mainline, I can then start
to work on my Devise branch again and try to make this test to
pass instead of that other functional one that is very specific to
the current solution.
First of all, let me see if I get this right: you're proposing to
merge the integration test only at this time, and then use that to
continue the work on Devise? Awesome!
That's exactly what I'm proposing.
How deep do you feel it's necessary to integrate the OpenID communication?
I would like to integrate in such a way that completely replacing the
OpenID implementation would still cause the test to pass without
modifications.
Personally, I'd think it would be sufficient to obtain an OpenID
request that represents a successful or failed authentication;
I don't think it's that easy to fully understand the protocol to check
for the request itself to see if it works. But feel free to implement
such a test if you're more familiar with the protocol.
in order to test the integration. I agree with Rot's readme's
arguments agains mocking this, but at the same time it feels like
overkill to run a separate OpenID server just to test the integration?
One thing that would probably be really fast is to create a Rack app
that's mounted at some URL when RAILS_ENV=test and produces canned
responses for successful or failed requests inside Gitorious itself.
Rots is a Rack app, it is probably possible to mount it in the Gitorious
application itself for the test environment. I'm just not sure if that
is enough isolation for making sure it would work with a separate OpenID
provider server. I can make some tests like this and measure how much
faster it would be... The problem I see with this approach is that
Bundler can have problems if Rots depends on a different version of
rack-openid (or some other gem) than Gitorious itself.
Another option could be to provide another OpenID implementation to
the controller - essentially replace the `authenticate_with_open_id`
implementation mixed into the controller with another one.
I'm not sure what you're proposing here...
From the top of my head I don't remember how the OpenID plugin
achieves the block-style syntax that makes things appear to happen in
sequence, but it's probably a question of checking request parameters?
I don't really want to dig into how OpenID protocol works. If you could
tell me exactly how it works having tests in mind in just a few lines, I
can try to use some gem like FakeWeb for writing this test that would
run faster.
Hugs,
Rodrigo.
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
