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@python.org > > http://mail.python.org/mailman/listinfo/tutor > > > _______________________________________________ > Tutor maillist - Tutor@python.org > http://mail.python.org/mailman/listinfo/tutor > _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor