[Tutor] A not-so-basic question...
Patric Michael
patric at usa.net
Tue Jan 4 03:03:30 CET 2005
Hello Kent...
> 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 see we have similarities. I purely hate having to rewrite something I've
already done once to satisfaction.
>
> 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.
Again, we are similar. In my case though, its primarily because I don't
do enough scripting to remember little things, like slices for example.
>
> ================
>
> 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.
I don't quite grasp "automated testing". And yes, I test in place
constantly, but it only ever gets tedious when I cant figure out why a
thing doesn't work. ;)
>
> 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
Ah. I see what you mean. Ironically I do just that. IF the final output is
supposed to go to a mailer module, I'll send it to a page to make sure
that whats supposed to be there shows up in print.
> 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.
It does make things MUCH easier. When I started out, I was cutting
from one script to another until I figured out what a "module" was.
Now the calls to the database I/O are nothing more than importing a
module or function. And because they were tested when being built, if
I send a dictionary to a module, I _know_ it will be inserted without
checking. Thats what you meant by abstracting, right?
>
> 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.
Yes, thank you. I am glad to see my original thoughts are supported.
Patric
>
>
> 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
> >
> _______________________________________________
> Tutor maillist - Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor
>
More information about the Tutor
mailing list