On Tue, Jan 29, 2002 at 10:23:45AM -0500, Shane Landrum wrote: > > When we first introduced this most of the reviews were for very > > basic things: you forgot strict or warnings. You didn't untaint that > > variable. You're not following our coding standards there. > Ah, ok. So were you just grepping each file for "use strict", or what?
Pretty much... You can automated quite a lot of 'policy' if you try hard enough ;) > > So we built as much of that as possible into our build script > Did people run that before their commits, or did they get mail after > they screwed up a commit? There was no way to screw up a commit like this. To have a change integrated you had to build it first, and then run the tests (theoretically a full regression test), then get it passed at review... Aegis handles all this for you. Only one thing can be integrated at a time, and aegis tries its best to merge conflicts automatically for you, and those it can't it highlights... It's not completely smooth, and you can get some bottlenecks, but it's a very useful system. > Your talking about this reminded me of a peeve I've had lately. > I need webpage testing that doesn't suck. In particular, I need > something like Inline::Webchat without its strange limitations. > I also need more abstraction. I've got a lot of Apache handlers > written in Perl which talk to databases and make web-based editing > forms. I need to do things like "okay, find each link that looks > like http://host/edit/thingy/?foo=(number)&action=(something). Now > click through all those pages and run tests on each one of them." > Hand coding all those tests could really suck, so I haven't even > tried. We've taken a completely different approach. Everything we do now for web work uses Template Toolkit, so all we do is simulate a web page request, faking up a CGI object with parameters, or a Mock::Apache object or whatever is needed, and then trap what gets passed to the template. So, for example, if you were testing a register page, you could do something like: use Test::More tests => 4; my $details = { username => 'fred', password => 'wibble', confirm => 'wibble', }; # test with missing confirm { local $details->{confirm} = ""; local *MySite::Page::cgi = sub { CGI->new($details) }; my $page = MySite::Page::Login->content; is $page->{error}, "You must reconfirm your password", "no reconfirm"; } # test with incorrect confirmed password { local $details->{confirm} = "wobble"; local *MySite::Page::cgi = sub { CGI->new($details) }; my $page = MySite::Page::Login->content; is $page->{error}, "Your passwords differed", "reconfirm wrong"; } # all OK { local *MySite::Page::cgi = sub { CGI->new($details) }; local *MySite::Page::redirect = sub { ::ok(1, "Redirecting to $_[1]") } my $page = MySite::Page::Login->content; is $page->{error}, undef, "We have no errors"; } Some of this depends on the way we have our Page classes set up, and we've abstracted some of this away (keep meaning to find a way of tidying it up much better) but the general principle is quite nice... Tony
