Louis Erickson wrote:
> I'm probably going to have several questions in the next few days about
> tests.
As usual in these parts, all questions welcome, although you implicitly
volunteered to document anything not covered in the Manual/documentation
already. Well volunteered in advance. ;_)
I'm going to number the suggested approaches as we go so I can summarise
at the end...
My tests are currently based on the stubs generated by myapp_create,
and use Catalyst::Test. I could move them to WWW::Mechanize::Catalyst if
it would help.
It generally makes things nicer, however I _do_ tend to just use
Catalyst::Test to test login / logout / etc, as I run some basic 'does
the app look sane' tests first up so that it's quick to just run the
front end sanity checks when developing...
I've then got various Mech & Selenium tests (which are much more
detailed and cover much more of the application / regressions etc) which
run after that..
Technique 1:
I can't tell if Catalyst::Test supports cookies. Does it? Or do I need
to use WWW::Mechanize::Catalyst for that?
It doesn't support cookies per-se, but it's not hard to handle this
yourself. For a nice neat example against the tutorial of testing login,
see:
http://github.com/bobtfish/catalyst-app-tutorial-kiffin-authissues/blob/cbb7f692676ecd51805dd7cc6cf4393ff6c208c5/t/01app.t
I've read some suggestions on how to go about this, and found a couple.
Technique 2:
1> Use WWW::Mechanize::Catalyst to log the user in
Works exactly like you'd expect :)
Technique 3:
2> Use the mock user in config to set a user who is logged in.
The second example is also fairly possible. I've never gone the whole
hog and had an entirely fake user object, although I do have tests which
apply a custom MYAPP_CONFIG environment variable, and have config which
overwrites my authentication config
I can set a mock user, but then that user is always logged in. Can that
mock user be changed by the test scripts, so I can have them log out, log
in as an administrator, log in as an unprivileged user, etc, and test the
pages perform correctly? If so, I've missed that - it would work, I
think.
Well, sure:
package My::Mock::User;
use strict;
use warnings;
use base qw/Catalyst::Authentication::User/;
our $id;
sub id { $id }
our @roles;
sub { @roles }
etc..
Then, assuming your tests and application are running in the same
process space, you can just say:
$My::Mock::User::id = 1;
$My::Mock::User::roles = qw/ admin /;
Technique 4:
The SSO is available to me as a library. I'm considering adding a login
page to the application, so the test scripts can log in to the SSO through
the application and solve the problem. Is duplicating a little code (not
much, most of it is in a module) to make tests work a good idea?
That's also viable in my opinion.
I mean - you're not trying to test the SSO itself, just how users who
have logged in with SSO behave, right?
In fact, if you add t/lib/MyApp/Controller/Login/Testing.pm
then that controller will only be loaded in your tests which have said;
use FindBin ();
use lib "$FindBin::Bin/lib";
I'd want the application-specific login page to only be available while
the test scripts are running. In production it shouldn't exist or at the
worst redirect back to the real SSO login page. Writing a function which
behaves differently in test seems like a source of errors to me. Does
this sound possible?
As noted above, just locate the files inside the test suite, but in your
application namespace. They'll not be installed with the rest of your
app (if you install your apps), and won't be loaded except in your
tests, or if you perl -It/lib script/myapp_server.pl yourself.
Technique 5:
Can I just generate the cookie and put it in the cookie store directly
before the query is made to the application? I can generate the cookie
with the SSO library. I don't see a way to do that through either test
tool.
Erm, yes - this will also work..
Don't think at the Catalyst::Test level here - your cookie is stored as
a row in DBIC (assuming you are using DBIC), just generate a row with a
known cookie value before you start testing :)
I'm trying to learn and do this in a maintainable, sensible way. Any help
you can give is highly appreciated.
I think that number 1 needs better docs in Catalyst::Test, and is a
viable technique, but painful to write all your testing in Catalyst::Test.
Number (2) just works. I'd note that I generally use Mech for
walk-through type testing, and either Catalyst::Test to test specific
regressions, or controller mocking if I _really_ need to to test stuff,
and everything else is in my Model and can be tested in isolation..
3 + 5 would probably win for maintainability in my opinion, as they'd be
best implemented generically as additional modules which other people
can reuse for the relevant bits of Auth and Session respectively, and
I'll be happy to maintain the patches you supply.
I'm more keen on 3 actually, as I guess that'd be the easiest way to
avoid testing authentication at all where you want to get on with
testing the rest of your app.
4 makes sense in some situations - you need testing of login / roles
etc, but given you've already done that, the rest of your app testing
not having to mess around with that stuff could be cleaner - although
I'd be tempted to think you should just factor the 'hand me back a
logged in user' code out into a test library, or that you should mock
the login code out, rather than adding extra login code.
Thanks
t0m
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
