[Tutor] A not-so-basic question...
Kent Johnson
kent37 at tds.net
Mon Jan 3 13:37:58 CET 2005
Patric,
I am a strong proponent of
- incremental development
- unit testing and test-first (or at least test-concurrent) programming
- Don't Repeat Yourself and merciless refactoring
I look for a small piece of a problem, or a simplification of the problem, and write some code. I
write unit tests for the code as I go. When I have the first bit working, I add some more. I
refactor to improve the clarity of the code and avoid duplication.
================
Look for a way to automate your tests. If you are writing a CGI and testing it in place with a web
browser, the testing will quickly become tedious and you will rarely test more than the last code
that you wrote. If your tests are automated and quick, you can run many tests at once. That way you
have confidence that you haven't broken anything.
In your example, automated testing may be a challenge. If I understand correctly, you are basically
getting data from a form and putting it into an email. Some suggestions:
- If there is any manipulation of the data in the middle, you can break that into functions and test
those functions separately.
- You can abstract the mailer into a generic back end. Then you can make a test version that doesn't
actually send any mail, but that lets you verify that the program asked for mail to be sent. Then
use an automated tester for web apps to drive the front end and make sure the back end is called
correctly.
- This thread on comp.lang.python about unit testing CGIs may be helpful:
http://tinyurl.com/5yr4c
It can take some work to set up a test jig but I find it usually pays off. Once you have done it
once you will have the techniques down and you can use the same techniques in similar projects.
================
Look for duplication in your code and don't tolerate it. Not only in a single project but between
projects. If you are writing many similar CGIs you should be building up a library of tested support
modules that you can re-use. This will make subsequent projects easier.
Whenever you are tempted to copy and paste code, look for a way to abstract the code into a function
or class so the copying is not needed.
Whenever you are tempted to copy and paste data, look for a way to centralize the data so all
clients work from the same reference.
HTH,
Kent
Patric Michael wrote:
> Hi folks...
>
> I was thinking about this the other day while prepping to write up
> another CGI thing.
> It occurred to me to wonder how other folks prepare an app, script,
> whatever.
> So the question is, and I am not looking for a "right answer" here. (I
> doubt ther eis one, to be honest.)
>
> How do you go about setting up a new application?
>
> For example, suppose I need a script that will collect order information
> for a set of items ona page. Its output will go to a mail program so the
> artist can be notified.
> I know that the script needs to be somewhat customizable since more
> than one person will use it, and I want to look to the future where such a
> script might get superceded for something like credit card orders, or
> possible integration with a larger order processing scheme.
>
> I'd start out by commenting goals in a new file, like so:
>
> ------------------------------
> # Initialize variables
>
> # Gather form data
>
> # Output results
> --------------------------------------
> Then I'd go back through each comment and either call modules I've
> prewritten, or write new defs.
> Then I'd add import statements to cover the modules and the defs:
>
> ----------------------------------
> from datetime import now
> import cgi
> from mailman import send
>
> # Initialize variables
> form = cgi.FieldStorage()
>
> # Gather form data
> for each in form:
> blah
> blah
>
> # Output results
> result = {}
> send(result)
>
> ----------------------------------------
>
> And so on.
>
> So the question is, how do you do it?
>
> Is there a method you prefer? Something tried and true, or maybe
> foolproof?
>
> Just curious... And maybe a bit hopeful someone has a better way than
> mine. Seems like I do an awful lot of testing... :)
>
> Patric
>
> _______________________________________________
> Tutor maillist - Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor
>
More information about the Tutor
mailing list