[Tutor] A not-so-basic question...

[Patric Michael]

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
>