I''ve just begin using rspec stories, and i m encountering some
problems. In my application i have different subdomains in which
specific users can log in, for example an admin will go to
admin.myapp.com/authenticate/login, and an user belonging to a
specific company will log in company.myapp.com/authenticate/login, and
of course both have a different login process.
To perform some actions the user has to be logged in, and this is
where the problem comes, how to test these actions ?
- Is there a way to set a user as logged in ? (that would definitely
be very convenient)
So far I have tried to do the following :
post "/authenticate/login",
{:login => user_email,
:password => password }
but the problem is that it doesn''t use the correct subdomain and the
login, as expected in that case, fails, so how to define the correct
subdomain ?
Thank you in advance for your help.
On Wed, Mar 5, 2008 at 4:30 PM, Bastien <bastien.vaucher at gmail.com> wrote:> I''ve just begin using rspec stories, and i m encountering some > problems. In my application i have different subdomains in which > specific users can log in, for example an admin will go to > admin.myapp.com/authenticate/login, and an user belonging to a > specific company will log in company.myapp.com/authenticate/login, and > of course both have a different login process. > > To perform some actions the user has to be logged in, and this is > where the problem comes, how to test these actions ? > > - Is there a way to set a user as logged in ? (that would definitely > be very convenient) > > So far I have tried to do the following : > > post "/authenticate/login", > {:login => user_email, > :password => password } > > but the problem is that it doesn''t use the correct subdomain and the > login, as expected in that case, fails, so how to define the correct > subdomain ?RailsStory wraps ActionController::IntegrationTest, which delegates calls to ActionController::Integration::Session. Check out the rdoc (http://api.rubyonrails.com/classes/ActionController/Integration/Session.html) and you''ll see a host! method (http://api.rubyonrails.com/classes/ActionController/Integration/Session.html#M000237). So ... host! "whatever subdomain" post "/authenticate/login", .... Cheers, David> > Thank you in advance for your help. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
I think you can also use:
post "/authentication/login",
{ :login => user_email,
:password => password },
:host => "company.example.com"
Op 5-mrt-08, om 23:30 heeft Bastien het volgende geschreven:
> I''ve just begin using rspec stories, and i m encountering some
> problems. In my application i have different subdomains in which
> specific users can log in, for example an admin will go to
> admin.myapp.com/authenticate/login, and an user belonging to a
> specific company will log in company.myapp.com/authenticate/login, and
> of course both have a different login process.
>
> To perform some actions the user has to be logged in, and this is
> where the problem comes, how to test these actions ?
>
> - Is there a way to set a user as logged in ? (that would definitely
> be very convenient)
>
> So far I have tried to do the following :
>
> post "/authenticate/login",
> {:login => user_email,
> :password => password }
>
> but the problem is that it doesn''t use the correct subdomain and
the
> login, as expected in that case, fails, so how to define the correct
> subdomain ?
>
> Thank you in advance for your help.
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
Thanks David, this works just fine. I would rather do some stubbing
there if it''s possible though. I tried :
ApplicationController.stub!
(:user_authentication_required).and_return(true)
(which is the filter called before each action that checks whether the
user is logged in or not)
But it doesn''t work. When I do this :
class ApplicationController
def user_authentication_required
return true
end
end
it works fine (but I find it quite dirty to redefine my method that
way). Aren''t this two solutions supposed to give me the same result ?
Is something wrong with my stubbing ?
On Mar 6, 3:33 pm, Ivo Dancet <ivo.dan... at gmail.com>
wrote:> I think you can also use:
>
> post "/authentication/login",
> { :login => user_email,
> :password => password },
> :host => "company.example.com"
>
> Op 5-mrt-08, om 23:30 heeft Bastien het volgende geschreven:
>
>
>
> > I''ve just begin using rspec stories, and i m encountering
some
> > problems. In my application i have different subdomains in which
> > specific users can log in, for example an admin will go to
> > admin.myapp.com/authenticate/login, and an user belonging to a
> > specific company will log in company.myapp.com/authenticate/login, and
> > of course both have a different login process.
>
> > To perform some actions the user has to be logged in, and this is
> > where the problem comes, how to test these actions ?
>
> > - Is there a way to set a user as logged in ? (that would definitely
> > be very convenient)
>
> > So far I have tried to do the following :
>
> > post "/authenticate/login",
> > {:login => user_email,
> > :password => password }
>
> > but the problem is that it doesn''t use the correct subdomain
and the
> > login, as expected in that case, fails, so how to define the correct
> > subdomain ?
>
> > Thank you in advance for your help.
> > _______________________________________________
> > rspec-users mailing list
> > rspec-us... at rubyforge.org
> >http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-us... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
On Thu, Mar 6, 2008 at 7:12 AM, Bastien <bastien.vaucher at gmail.com> wrote:> Thanks David, this works just fine. I would rather do some stubbing > there if it''s possible though. I tried : > > ApplicationController.stub! > (:user_authentication_required).and_return(true)try controller.stub!(....) Pat
On Thu, Mar 6, 2008 at 7:23 AM, Pat Maddox <pergesu at gmail.com> wrote:> On Thu, Mar 6, 2008 at 7:12 AM, Bastien <bastien.vaucher at gmail.com> wrote: > > Thanks David, this works just fine. I would rather do some stubbing > > there if it''s possible though. I tried : > > > > ApplicationController.stub! > > (:user_authentication_required).and_return(true) > > try > controller.stub!(....)Perhaps I should explain why this is. stub! adds a stubbed method to an object. In Ruby, classes are objects as well, so what you''ve done is to stub a method on the ApplicationController class object itself - effectively creating a class method. When you override the method yourself, you''re overriding an instance method. So in order to stub out the method for a request, you want to stub it on the _instance_ of the controller being used in the test. That controller instance is made available to you through a method named "controller". Pat
You should not stub the authentication method in a story. The story should test the whole application framework, that way your story might look like this: Given a user from company x When logging in And requesting some page Then the application should do all the stuff it should In the given step you set your host, user name and password and you create that user. In the when steps you make the login request and then you can start doing the stuff you really want to test here as you''ll have the session you want at that moment. Regards Ivo Dancet Op 6-mrt-08, om 16:12 heeft Bastien het volgende geschreven:> Thanks David, this works just fine. I would rather do some stubbing > there if it''s possible though. I tried : > > ApplicationController.stub! > (:user_authentication_required).and_return(true) > > (which is the filter called before each action that checks whether the > user is logged in or not) > But it doesn''t work. When I do this : > > class ApplicationController > def user_authentication_required > return true > end > end > > it works fine (but I find it quite dirty to redefine my method that > way). Aren''t this two solutions supposed to give me the same result ? > Is something wrong with my stubbing ? > > On Mar 6, 3:33 pm, Ivo Dancet <ivo.dan... at gmail.com> wrote: >> I think you can also use: >> >> post "/authentication/login", >> { :login => user_email, >> :password => password }, >> :host => "company.example.com" >> >> Op 5-mrt-08, om 23:30 heeft Bastien het volgende geschreven: >> >> >> >>> I''ve just begin using rspec stories, and i m encountering some >>> problems. In my application i have different subdomains in which >>> specific users can log in, for example an admin will go to >>> admin.myapp.com/authenticate/login, and an user belonging to a >>> specific company will log in company.myapp.com/authenticate/login, >>> and >>> of course both have a different login process. >> >>> To perform some actions the user has to be logged in, and this is >>> where the problem comes, how to test these actions ? >> >>> - Is there a way to set a user as logged in ? (that would definitely >>> be very convenient) >> >>> So far I have tried to do the following : >> >>> post "/authenticate/login", >>> {:login => user_email, >>> :password => password } >> >>> but the problem is that it doesn''t use the correct subdomain and the >>> login, as expected in that case, fails, so how to define the correct >>> subdomain ? >> >>> Thank you in advance for your help. >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-us... at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >> >> _______________________________________________ >> rspec-users mailing list >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
On Thu, Mar 6, 2008 at 7:27 AM, Ivo Dancet <ivo.dancet at gmail.com> wrote:> You should not stub the authentication method in a story. The story > should test the whole application framework, that way your story might > look like this: > > Given a user from company x > When logging in > And requesting some page > Then the application should do all the stuff it should > > In the given step you set your host, user name and password and you > create that user. > In the when steps you make the login request and then you can start > doing the stuff you really want to test here as you''ll have the > session you want at that moment.That''s a little too dogmatic for me. You needn''t go through the entire stack every story, and you needn''t go through the entire app path either. That said, I think you want to keep stubbing to an absolute minimum. I only stub out stuff that hits external services - even then I have a "full integration mode" that runs the same tests but DOES hit the real services (assuming they provide a sandbox or I have some other innocuous way to mess with stuff). Sometimes I''m lazy about the login step and will do controller.send(:current_user=, User.find(1)) if I don''t feel there''s any benefit at all to making a login request. Pat
Thanks for your help. I tried the controller.stub!(...) as well, and it doesn''t work. Ivo I totally agree with you and I''ll follow your recommendations, thanks. (Would still be nice to know if the stubbing could work or if it''s intended not to) On Mar 6, 4:27 pm, Ivo Dancet <ivo.dan... at gmail.com> wrote:> You should not stub the authentication method in a story. The story > should test the whole application framework, that way your story might > look like this: > > Given a user from company x > When logging in > And requesting some page > Then the application should do all the stuff it should > > In the given step you set your host, user name and password and you > create that user. > In the when steps you make the login request and then you can start > doing the stuff you really want to test here as you''ll have the > session you want at that moment. > > Regards > Ivo Dancet > > Op 6-mrt-08, om 16:12 heeft Bastien het volgende geschreven: > > > > > Thanks David, this works just fine. I would rather do some stubbing > > there if it''s possible though. I tried : > > > ApplicationController.stub! > > (:user_authentication_required).and_return(true) > > > (which is the filter called before each action that checks whether the > > user is logged in or not) > > But it doesn''t work. When I do this : > > > class ApplicationController > > def user_authentication_required > > return true > > end > > end > > > it works fine (but I find it quite dirty to redefine my method that > > way). Aren''t this two solutions supposed to give me the same result ? > > Is something wrong with my stubbing ? > > > On Mar 6, 3:33 pm, Ivo Dancet <ivo.dan... at gmail.com> wrote: > >> I think you can also use: > > >> post "/authentication/login", > >> { :login => user_email, > >> :password => password }, > >> :host => "company.example.com" > > >> Op 5-mrt-08, om 23:30 heeft Bastien het volgende geschreven: > > >>> I''ve just begin using rspec stories, and i m encountering some > >>> problems. In my application i have different subdomains in which > >>> specific users can log in, for example an admin will go to > >>> admin.myapp.com/authenticate/login, and an user belonging to a > >>> specific company will log in company.myapp.com/authenticate/login, > >>> and > >>> of course both have a different login process. > > >>> To perform some actions the user has to be logged in, and this is > >>> where the problem comes, how to test these actions ? > > >>> - Is there a way to set a user as logged in ? (that would definitely > >>> be very convenient) > > >>> So far I have tried to do the following : > > >>> post "/authenticate/login", > >>> {:login => user_email, > >>> :password => password } > > >>> but the problem is that it doesn''t use the correct subdomain and the > >>> login, as expected in that case, fails, so how to define the correct > >>> subdomain ? > > >>> Thank you in advance for your help. > >>> _______________________________________________ > >>> rspec-users mailing list > >>> rspec-us... at rubyforge.org > >>>http://rubyforge.org/mailman/listinfo/rspec-users > > >> _______________________________________________ > >> rspec-users mailing list > >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > > rspec-users mailing list > > rspec-us... at rubyforge.org > >http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
On Thu, Mar 6, 2008 at 10:38 AM, Pat Maddox <pergesu at gmail.com> wrote:> On Thu, Mar 6, 2008 at 7:27 AM, Ivo Dancet <ivo.dancet at gmail.com> wrote: > > You should not stub the authentication method in a story. The story > > should test the whole application framework, that way your story might > > look like this: > > > > Given a user from company x > > When logging in > > And requesting some page > > Then the application should do all the stuff it should > > > > In the given step you set your host, user name and password and you > > create that user. > > In the when steps you make the login request and then you can start > > doing the stuff you really want to test here as you''ll have the > > session you want at that moment. > > That''s a little too dogmatic for me. You needn''t go through the > entire stack every story, and you needn''t go through the entire app > path either. >IMO you should be simulating as much as possible what the user is doing. If they have to go through path a, b, c ... to get to Z, then so be it. This involves keeping a well-factored set of helpers which can be used to navigate the app just like a user would. The only things you probably should be stubbing in a story are third party components your site may have to integrate with that aren''t realistic to be run for every story (for the most part, there are other exceptions as well I know). I would avoid stubbing core functionality related to your site, -- Zach Dennis http://www.continuousthinking.com
I found it a little confusing to stub my authentication filters as well, but
figured it out with a little help from the interwebs:
in spec_helper i have this:
describe "a controller requiring login", :shared => true do
it "should have login_required set in the before filter" do
controller.class.before_filters.should include(:login_required)
end
end
def mock_login_required(allow_user_to_pass=true)
controller.stub!(:login_required).and_return(allow_user_to_pass)
end
Then, in any spec where i want to mock that filter, i just write
it_should_behave_like "a controller requiring login"
at the top of the describe block.
Sorry, i can''t remember the web page where i found this solution but
respect
to whoever posted it :)
On 06/03/2008, Bastien <bastien.vaucher at gmail.com>
wrote:>
> Thanks for your help.
> I tried the controller.stub!(...) as well, and it doesn''t work.
>
> Ivo I totally agree with you and I''ll follow your recommendations,
> thanks.
>
> (Would still be nice to know if the stubbing could work or if it''s
> intended not to)
>
>
> On Mar 6, 4:27 pm, Ivo Dancet <ivo.dan... at gmail.com> wrote:
> > You should not stub the authentication method in a story. The story
> > should test the whole application framework, that way your story might
> > look like this:
> >
> > Given a user from company x
> > When logging in
> > And requesting some page
> > Then the application should do all the stuff it should
> >
> > In the given step you set your host, user name and password and you
> > create that user.
> > In the when steps you make the login request and then you can start
> > doing the stuff you really want to test here as you''ll have
the
> > session you want at that moment.
> >
> > Regards
> > Ivo Dancet
> >
> > Op 6-mrt-08, om 16:12 heeft Bastien het volgende geschreven:
> >
> >
> >
> > > Thanks David, this works just fine. I would rather do some
stubbing
> > > there if it''s possible though. I tried :
> >
> > > ApplicationController.stub!
> > > (:user_authentication_required).and_return(true)
> >
> > > (which is the filter called before each action that checks
whether the
> > > user is logged in or not)
> > > But it doesn''t work. When I do this :
> >
> > > class ApplicationController
> > > def user_authentication_required
> > > return true
> > > end
> > > end
> >
> > > it works fine (but I find it quite dirty to redefine my method
that
> > > way). Aren''t this two solutions supposed to give me the
same result ?
> > > Is something wrong with my stubbing ?
> >
> > > On Mar 6, 3:33 pm, Ivo Dancet <ivo.dan... at gmail.com>
wrote:
> > >> I think you can also use:
> >
> > >> post "/authentication/login",
> > >> { :login => user_email,
> > >> :password => password },
> > >> :host => "company.example.com"
> >
> > >> Op 5-mrt-08, om 23:30 heeft Bastien het volgende geschreven:
> >
> > >>> I''ve just begin using rspec stories, and i m
encountering some
> > >>> problems. In my application i have different subdomains
in which
> > >>> specific users can log in, for example an admin will go
to
> > >>> admin.myapp.com/authenticate/login, and an user belonging
to a
> > >>> specific company will log in
company.myapp.com/authenticate/login,
> > >>> and
> > >>> of course both have a different login process.
> >
> > >>> To perform some actions the user has to be logged in, and
this is
> > >>> where the problem comes, how to test these actions ?
> >
> > >>> - Is there a way to set a user as logged in ? (that would
definitely
> > >>> be very convenient)
> >
> > >>> So far I have tried to do the following :
> >
> > >>> post "/authenticate/login",
> > >>> {:login => user_email,
> > >>> :password => password }
> >
> > >>> but the problem is that it doesn''t use the
correct subdomain and the
> > >>> login, as expected in that case, fails, so how to define
the correct
> > >>> subdomain ?
> >
> > >>> Thank you in advance for your help.
> > >>> _______________________________________________
> > >>> rspec-users mailing list
> > >>> rspec-us... at rubyforge.org
> > >>>http://rubyforge.org/mailman/listinfo/rspec-users
> >
> > >> _______________________________________________
> > >> rspec-users mailing list
> > >> rspec-us... at rubyforge
> .orghttp://rubyforge.org/mailman/listinfo/rspec-users
> > > _______________________________________________
> > > rspec-users mailing list
> > > rspec-us... at rubyforge.org
> > >http://rubyforge.org/mailman/listinfo/rspec-users
> >
> > _______________________________________________
> > rspec-users mailing list
> > rspec-us... at rubyforge
> .orghttp://rubyforge.org/mailman/listinfo/rspec-users
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/rspec-users/attachments/20080307/78046744/attachment.html
Oh, sorry, and this line in your specs to actually mock the filter: mock_login_required :) On 07/03/2008, Max Williams <toastkid.williams at gmail.com> wrote:> > I found it a little confusing to stub my authentication filters as well, > but figured it out with a little help from the interwebs: > > in spec_helper i have this: > > describe "a controller requiring login", :shared => true do > it "should have login_required set in the before filter" do > controller.class.before_filters.should include(:login_required) > end > end > > def mock_login_required(allow_user_to_pass=true) > controller.stub!(:login_required).and_return(allow_user_to_pass) > end > > Then, in any spec where i want to mock that filter, i just write > > it_should_behave_like "a controller requiring login" > > at the top of the describe block. > > Sorry, i can''t remember the web page where i found this solution but > respect to whoever posted it :) > > On 06/03/2008, Bastien <bastien.vaucher at gmail.com> wrote: > > > > Thanks for your help. > > I tried the controller.stub!(...) as well, and it doesn''t work. > > > > Ivo I totally agree with you and I''ll follow your recommendations, > > thanks. > > > > (Would still be nice to know if the stubbing could work or if it''s > > intended not to) > > > > > > On Mar 6, 4:27 pm, Ivo Dancet <ivo.dan... at gmail.com> wrote: > > > You should not stub the authentication method in a story. The story > > > should test the whole application framework, that way your story might > > > look like this: > > > > > > Given a user from company x > > > When logging in > > > And requesting some page > > > Then the application should do all the stuff it should > > > > > > In the given step you set your host, user name and password and you > > > create that user. > > > In the when steps you make the login request and then you can start > > > doing the stuff you really want to test here as you''ll have the > > > session you want at that moment. > > > > > > Regards > > > Ivo Dancet > > > > > > Op 6-mrt-08, om 16:12 heeft Bastien het volgende geschreven: > > > > > > > > > > > > > Thanks David, this works just fine. I would rather do some stubbing > > > > there if it''s possible though. I tried : > > > > > > > ApplicationController.stub! > > > > (:user_authentication_required).and_return(true) > > > > > > > (which is the filter called before each action that checks whether > > the > > > > user is logged in or not) > > > > But it doesn''t work. When I do this : > > > > > > > class ApplicationController > > > > def user_authentication_required > > > > return true > > > > end > > > > end > > > > > > > it works fine (but I find it quite dirty to redefine my method that > > > > way). Aren''t this two solutions supposed to give me the same result > > ? > > > > Is something wrong with my stubbing ? > > > > > > > On Mar 6, 3:33 pm, Ivo Dancet <ivo.dan... at gmail.com> wrote: > > > >> I think you can also use: > > > > > > >> post "/authentication/login", > > > >> { :login => user_email, > > > >> :password => password }, > > > >> :host => "company.example.com" > > > > > > >> Op 5-mrt-08, om 23:30 heeft Bastien het volgende geschreven: > > > > > > >>> I''ve just begin using rspec stories, and i m encountering some > > > >>> problems. In my application i have different subdomains in which > > > >>> specific users can log in, for example an admin will go to > > > >>> admin.myapp.com/authenticate/login, and an user belonging to a > > > >>> specific company will log in company.myapp.com/authenticate/login, > > > >>> and > > > >>> of course both have a different login process. > > > > > > >>> To perform some actions the user has to be logged in, and this is > > > >>> where the problem comes, how to test these actions ? > > > > > > >>> - Is there a way to set a user as logged in ? (that would > > definitely > > > >>> be very convenient) > > > > > > >>> So far I have tried to do the following : > > > > > > >>> post "/authenticate/login", > > > >>> {:login => user_email, > > > >>> :password => password } > > > > > > >>> but the problem is that it doesn''t use the correct subdomain and > > the > > > >>> login, as expected in that case, fails, so how to define the > > correct > > > >>> subdomain ? > > > > > > >>> Thank you in advance for your help. > > > >>> _______________________________________________ > > > >>> rspec-users mailing list > > > >>> rspec-us... at rubyforge.org > > > >>>http://rubyforge.org/mailman/listinfo/rspec-users > > > > > > >> _______________________________________________ > > > >> rspec-users mailing list > > > >> rspec-us... at rubyforge > > .orghttp://rubyforge.org/mailman/listinfo/rspec-users > > > > _______________________________________________ > > > > rspec-users mailing list > > > > rspec-us... at rubyforge.org > > > >http://rubyforge.org/mailman/listinfo/rspec-users > > > > > > _______________________________________________ > > > rspec-users mailing list > > > rspec-us... at rubyforge > > .orghttp://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20080307/1b516a6d/attachment-0001.html
We do something very very similar but rather then it_should_behave_like we wrap it in a it_requires_login method... describe SomeController do it_requires_login end Zach On Fri, Mar 7, 2008 at 11:53 AM, Max Williams <toastkid.williams at gmail.com> wrote:> I found it a little confusing to stub my authentication filters as well, but > figured it out with a little help from the interwebs: > > in spec_helper i have this: > > describe "a controller requiring login", :shared => true do > it "should have login_required set in the before filter" do > controller.class.before_filters.should include(:login_required) > end > end > > def mock_login_required(allow_user_to_pass=true) > controller.stub!(:login_required).and_return(allow_user_to_pass) > end > > Then, in any spec where i want to mock that filter, i just write > > it_should_behave_like "a controller requiring login" > > at the top of the describe block. > > Sorry, i can''t remember the web page where i found this solution but respect > to whoever posted it :) > > > > On 06/03/2008, Bastien <bastien.vaucher at gmail.com> wrote: > > Thanks for your help. > > I tried the controller.stub!(...) as well, and it doesn''t work. > > > > Ivo I totally agree with you and I''ll follow your recommendations, > > thanks. > > > > (Would still be nice to know if the stubbing could work or if it''s > > intended not to) > > > > > > On Mar 6, 4:27 pm, Ivo Dancet <ivo.dan... at gmail.com> wrote: > > > You should not stub the authentication method in a story. The story > > > should test the whole application framework, that way your story might > > > look like this: > > > > > > Given a user from company x > > > When logging in > > > And requesting some page > > > Then the application should do all the stuff it should > > > > > > In the given step you set your host, user name and password and you > > > create that user. > > > In the when steps you make the login request and then you can start > > > doing the stuff you really want to test here as you''ll have the > > > session you want at that moment. > > > > > > Regards > > > Ivo Dancet > > > > > > Op 6-mrt-08, om 16:12 heeft Bastien het volgende geschreven: > > > > > > > > > > > > > Thanks David, this works just fine. I would rather do some stubbing > > > > there if it''s possible though. I tried : > > > > > > > ApplicationController.stub! > > > > (:user_authentication_required).and_return(true) > > > > > > > (which is the filter called before each action that checks whether the > > > > user is logged in or not) > > > > But it doesn''t work. When I do this : > > > > > > > class ApplicationController > > > > def user_authentication_required > > > > return true > > > > end > > > > end > > > > > > > it works fine (but I find it quite dirty to redefine my method that > > > > way). Aren''t this two solutions supposed to give me the same result ? > > > > Is something wrong with my stubbing ? > > > > > > > On Mar 6, 3:33 pm, Ivo Dancet <ivo.dan... at gmail.com> wrote: > > > >> I think you can also use: > > > > > > >> post "/authentication/login", > > > >> { :login => user_email, > > > >> :password => password }, > > > >> :host => "company.example.com" > > > > > > >> Op 5-mrt-08, om 23:30 heeft Bastien het volgende geschreven: > > > > > > >>> I''ve just begin using rspec stories, and i m encountering some > > > >>> problems. In my application i have different subdomains in which > > > >>> specific users can log in, for example an admin will go to > > > >>> admin.myapp.com/authenticate/login, and an user belonging to a > > > >>> specific company will log in company.myapp.com/authenticate/login, > > > >>> and > > > >>> of course both have a different login process. > > > > > > >>> To perform some actions the user has to be logged in, and this is > > > >>> where the problem comes, how to test these actions ? > > > > > > >>> - Is there a way to set a user as logged in ? (that would definitely > > > >>> be very convenient) > > > > > > >>> So far I have tried to do the following : > > > > > > >>> post "/authenticate/login", > > > >>> {:login => user_email, > > > >>> :password => password } > > > > > > >>> but the problem is that it doesn''t use the correct subdomain and the > > > >>> login, as expected in that case, fails, so how to define the correct > > > >>> subdomain ? > > > > > > >>> Thank you in advance for your help. > > > >>> _______________________________________________ > > > >>> rspec-users mailing list > > > >>> rspec-us... at rubyforge.org > > > >>>http://rubyforge.org/mailman/listinfo/rspec-users > > > > > > >> _______________________________________________ > > > >> rspec-users mailing list > > > >> > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > > > _______________________________________________ > > > > rspec-users mailing list > > > > rspec-us... at rubyforge.org > > > >http://rubyforge.org/mailman/listinfo/rspec-users > > > > > > _______________________________________________ > > > rspec-users mailing list > > > > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-- Zach Dennis http://www.continuousthinking.com
In case it isn''t clear... I agree with Ivo''s statement: "You should not stub the authentication method in a story. The story should test the whole application framework". emphasis on "story" Zach On Fri, Mar 7, 2008 at 11:13 AM, Zach Dennis <zach.dennis at gmail.com> wrote:> On Thu, Mar 6, 2008 at 10:38 AM, Pat Maddox <pergesu at gmail.com> wrote: > > On Thu, Mar 6, 2008 at 7:27 AM, Ivo Dancet <ivo.dancet at gmail.com> wrote: > > > You should not stub the authentication method in a story. The story > > > should test the whole application framework, that way your story might > > > look like this: > > > > > > Given a user from company x > > > When logging in > > > And requesting some page > > > Then the application should do all the stuff it should > > > > > > In the given step you set your host, user name and password and you > > > create that user. > > > In the when steps you make the login request and then you can start > > > doing the stuff you really want to test here as you''ll have the > > > session you want at that moment. > > > > That''s a little too dogmatic for me. You needn''t go through the > > entire stack every story, and you needn''t go through the entire app > > path either. > > > > IMO you should be simulating as much as possible what the user is > doing. If they have to go through path a, b, c ... to get to Z, then > so be it. This involves keeping a well-factored set of helpers which > can be used to navigate the app just like a user would. > > The only things you probably should be stubbing in a story are third > party components your site may have to integrate with that aren''t > realistic to be run for every story (for the most part, there are > other exceptions as well I know). I would avoid stubbing core > functionality related to your site, > > -- > Zach Dennis > http://www.continuousthinking.com >-- Zach Dennis http://www.continuousthinking.com
Thanks to all of you, I added the login as a part of the story and now it works smoothly. On Mar 7, 9:35 pm, "Zach Dennis" <zach.den... at gmail.com> wrote:> In case it isn''t clear... I agree with Ivo''s statement: > > "You should not stub the authentication method in a story. The story > should test the whole application framework". > > emphasis on "story" > > Zach > > > > On Fri, Mar 7, 2008 at 11:13 AM, Zach Dennis <zach.den... at gmail.com> wrote: > > On Thu, Mar 6, 2008 at 10:38 AM, Pat Maddox <perg... at gmail.com> wrote: > > > On Thu, Mar 6, 2008 at 7:27 AM, Ivo Dancet <ivo.dan... at gmail.com> wrote: > > > > You should not stub the authentication method in a story. The story > > > > should test the whole application framework, that way your story might > > > > look like this: > > > > > Given a user from company x > > > > When logging in > > > > And requesting some page > > > > Then the application should do all the stuff it should > > > > > In the given step you set your host, user name and password and you > > > > create that user. > > > > In the when steps you make the login request and then you can start > > > > doing the stuff you really want to test here as you''ll have the > > > > session you want at that moment. > > > > That''s a little too dogmatic for me. You needn''t go through the > > > entire stack every story, and you needn''t go through the entire app > > > path either. > > > IMO you should be simulating as much as possible what the user is > > doing. If they have to go through path a, b, c ... to get to Z, then > > so be it. This involves keeping a well-factored set of helpers which > > can be used to navigate the app just like a user would. > > > The only things you probably should be stubbing in a story are third > > party components your site may have to integrate with that aren''t > > realistic to be run for every story (for the most part, there are > > other exceptions as well I know). I would avoid stubbing core > > functionality related to your site, > > > -- > > Zach Dennis > > http://www.continuousthinking.com > > -- > Zach Dennishttp://www.continuousthinking.com > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users