PERL CGI Beginners - How big is too big?

Author

How big is too big?

Bill Stephenson

2005-09-17, 7:55 am

How many lines of code does it take in a single CGI script to be
considered too big?

--
Bill Stephenson

Chris Devers

2005-09-17, 7:55 am

Randal L. Schwartz

2005-09-17, 6:55 pm

>>>>> "Bill" == Bill Stephenson <bills@perlhelp.com> writes:

Bill> How many lines of code does it take in a single CGI script to be
Bill> considered too big?

There are days when I wanna answer that as "3". :)

.... time passes ...

And I was just going to leave that as a joke answer, but on serious
reflection, your CGI "scripts" should be nothing more than
configuration and method calls against a testable module. It's hard
to test a script, but easy to test a module. Maybe that's why I like
frameworks such as Catalyst and my own CGI::Prototype so much... all
the heavy lifting is in testable modules.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Tony Frasketi

2005-09-17, 6:55 pm

And I was just going to leave that as a joke answer, but on serious

>reflection, your CGI "scripts" should be nothing more than
>configuration and method calls against a testable module. It's hard
>to test a script, but easy to test a module. Maybe that's why I like
>frameworks such as Catalyst and my own CGI::Prototype so much... all
>the heavy lifting is in testable modules.
>
>
>
I'm a newbee... Could you plase explain why it is easier to test a
module out than a CGI script and are you refering to modules you
yourself have created or modules other have created.
Tony

Ovid

2005-09-17, 6:55 pm

--- Tony Frasketi <webmaster@spacecovers.com> wrote:

> I'm a newbee... Could you plase explain why it is easier to test a
> module out than a CGI script and are you refering to modules you
> yourself have created or modules other have created.

When you get used to automated testing, you find that modules are much
easier to load and run tests against. For example, consider the
following snippet of code.

# Note that this is *not* how I would write this, but it
# illustrates the point.

package Foo;

use warnings;
use strict;
use base 'Exporter';
our @EXPORT_OK = qw/get_customer/;
use My::Customer;

sub get_customer {
my $cgi = shift;
my $_id = $cgi->param('customer_id') || '';

if ( my ($id) = $_id =~ /^(\d+)$/ ) {
return My::Customer->new($id);
}
else {
die "Bad customer id";
}
}

1;

And later in a test, it's easy to make sure it does what you want:

use Test::More qw/no_plan/;

my $module = 'Foo';
use_ok $module, 'get_customer' or die "Could not load $module";
can_ok __PACKAGE__, 'get_customer'; # get_customer was exported

my $cgi = $cgi->new( {customer_id => $customer_id});
ok my $cust = get_customer($cgi),
'... and we should be able to get a customer';
isa_ok $cust, 'My::Customer';

As you can see, but putting things into packages, we can make nicely
encapsulated functions or methods. By depending only on what they
accept and not having side-effects, it's very easy to write tests for
them. As a result, when you're testing some other code that
accidentally passes in a DBI object to get_customer(), it blows up
nicely, you find out from your tests (instead of your customers calling
to complain) and it's easy to fix.

Once I started testing, my code quality and overall productivity have
gone up quite a bit. Quality goes up because I discovered that code
which is easy to test is generally better code. Productivity has gone
up because developing higher quality code and constantly refactoring
means that my code base is much easier to work with. I'm rarely
"hacking around problems".

Cheers,
Ovid

--
If this message is a response to a question on a mailing list, please send
follow up questions to the list.

Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/

Tony Frasketi

2005-09-17, 6:55 pm

>
>
>As you can see, but putting things into packages, we can make nicely
>encapsulated functions or methods. By depending only on what they
>accept and not having side-effects, it's very easy to write tests for
>them. As a result, when you're testing some other code that
>accidentally passes in a DBI object to get_customer(), it blows up
>nicely, you find out from your tests (instead of your customers calling
>to complain) and it's easy to fix.
>
>Once I started testing, my code quality and overall productivity have
>gone up quite a bit. Quality goes up because I discovered that code
>which is easy to test is generally better code. Productivity has gone
>up because developing higher quality code and constantly refactoring
>means that my code base is much easier to work with. I'm rarely
>"hacking around problems".
>
>Cheers,
>Ovid
>
>

Thank a lot Ovid.... Your explanation enlightened me to the existance of
the variousTest modules...

Test::Harness <http://perldoc.perl.org/Test/Harness.html>

Test::Simple <http://perldoc.perl.org/Test/Simple.html>, Test::More
<http://perldoc.perl.org/Test/More.html>, Devel::Cover
<http://search.cpan.org/perldoc/Devel::Cover>

Test::Builder <http://perldoc.perl.org/Test/Builder.html> for building
your own testing library.

Test::Unit <http://search.cpan.org/perldoc/Test::Unit> is an interesting
XUnit-style testing library.

Test::Inline <http://search.cpan.org/perldoc/Test::Inline> and SelfTest
<http://search.cpan.org/perldoc/SelfTest> let you embed tests in code.

I'll be investigating these in the near future (a lot to read and
digest) and hopefully they will help me in testing my own modules.
By the way, are the use of these Test modules just as appropriate to use
in testing interactive CGI scripts as they are for scripts with no user
interfaces?
Thanks again
Tony

Ovid

2005-09-17, 6:55 pm

--- Tony Frasketi <webmaster@spacecovers.com> wrote:

> Thank a lot Ovid.... Your explanation enlightened me to the existance
> of the variousTest modules...

You're quite welcome.

> Test::Unit <http://search.cpan.org/perldoc/Test::Unit> is an
> interesting XUnit-style testing library.

I wouldn't use that. It's a dead module that is no longer used, as far
as I know. Instead, I highly recommend Test::Class. It's far more
Perlish and it's actively maintained by Adrian Howard.

> By the way, are the use of these Test modules just as appropriate to
> use
> in testing interactive CGI scripts as they are for scripts with no
> user interfaces?

Well, it you wish to test the interactivity of your CGI scripts, check
out Test::WWW::Mechanize. I think you'll be quite pleased with it.

Cheers,
Ovid

--
If this message is a response to a question on a mailing list, please send
follow up questions to the list.

Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/

Tony Frasketi

2005-09-17, 6:55 pm

Ovid wrote:

>--- Tony Frasketi <webmaster@spacecovers.com> wrote:
>
>
>
>
>You're quite welcome.
>
>
>
>
>I wouldn't use that. It's a dead module that is no longer used, as far
>as I know. Instead, I highly recommend Test::Class. It's far more
>Perlish and it's actively maintained by Adrian Howard.
>
>
>
>
>Well, it you wish to test the interactivity of your CGI scripts, check
>out Test::WWW::Mechanize. I think you'll be quite pleased with it.
>
>Cheers,
>Ovid
>
>
>

Thanks Ovid. Will check them out!
Tony

Bill Stephenson

2005-09-18, 6:55 pm

On Sep 17, 2005, at 8:29 AM, Randal L. Schwartz wrote:

> There are days when I wanna answer that as "3". :)

That's exactly how I felt when I asked this. :)

>
> ... time passes ...

And my script keeps getting bigger...

>
> And I was just going to leave that as a joke answer, but on serious
> reflection, your CGI "scripts" should be nothing more than
> configuration and method calls against a testable module.

Ok that makes sense. I sort of did this back in the days of using
"Libraries" of sub-routines but I've never really pushed myself over
the creating my own modules hump... I played a bit with an example
module I found online the last couple days and maybe I'm not as far
away from doing this as I thought... I'm not quite ready for
CGI::Prototype though. Randal, you're so far ahead of me I don't think
I can even see your dust, but I sure do enjoy following your footsteps.

On Sep 17, 2005, at 6:38 AM, Chris Devers wrote:

> When it gets to the point that you find it hard to maintain that way.

Yeah, I think I've reached that point.

>
> This threshold will be different for different people.
>
> When to start breaking things into smaller scripts -- just as when to
> start breaking things into smaller subroutines -- is largely a matter
> of
> personal preference, based on your own personal experience with writing
> and maintaining your code over time.
>

I guess the thing to do is to move my sub-routines into modules, and
create smaller scripts to handle specific user requests. This would be
more efficient (regarding server load) than one big script wouldn't it?

Thanks to all for the good advice,

--
Bill Stephenson

Sponsored Links