Oops, sorry, meant this for the list.

> On Mon, Oct 29, 2001 at 02:48:12PM -0500, Greg Ward wrote:
> >Have you tried setting DEBUG_LOG and sprinkling print statements into
> >your app?  It's crude and primitive, but it works.
>
> Agreed.  Inserting print statements and putting Quixote in RUN_ONCE
> mode is generally how I debug Quixote code.  That works nicely when
> sessions are fully persistent so you don't lose anything (except a bit
> of speed) by restarting the Quixote process all the time.

That's what I've been doing.  Except since I'm not using fully persistent
sessions and what I'm mostly interested in testing is the across-session
interaction, I wrote a class:

class Reset_publisher(Publisher_super):
    '''Modify the publisher to watch several files, and quit if they are
        modified.  Handy for resetting persistent scripts.
    '''
    def __init__(self, root_namespace, watch_files):
        self.watch_files = {}
        for s in watch_files:
            self.watch_files[s] = os.path.getmtime(s)
        Publisher_super.__init__(self, root_namespace)
    def start_request(self, request):
        # this means the current request will work normally, but the next
        # one will reset.  would it be better to throw up a blank page?
        for f, mtime in self.watch_files.items():
            if mtime != os.path.getmtime(f):
                self.exit_now = 1
                break
        Publisher_super.start_request(self, request)

Except the annoyance of having to hit the site a couple times to reset it, and
then having to log in all over again (made easier by having _q_access auto
log me in for debugging mode), print statements have worked ok so far (and
that's usually how I debug python anyway).  Occaisionally, though, something
really weird comes up and I waste a lot of time futzing with print statements
and traceback.print_stack()s, etc.

What I'd really like to do is have the the debugger always attached to the
running-over-the-web process and activate when I ask it to or an exception
occurs.  Then instead of putting prints in the source and trying to recreate
what I just did, I can type my prints right there.  Better yet if the debugger
checkpointed the process's state changes so I could backtrack (wouldn't work
for interactions with external resources though).  I suspect the first is
possible with python and pdb, and the second is not possible with python at
all :)

> >Definitely!  Neil cooked up something like that many moons ago, but it
> >never really went beyond prototype.  I also don't think it's that useful
>
> We'd love to have a way of regression-testing our Web site, but it's
> difficult to see how that would work.  It should be possible to write
> unit tests for simple little PTL functions, no different from how
> you'd test a regular Python function.  It's also easy to automatically
> hit a bunch of URLs that should work and verify that they don't return
> a 5xx HTTP response.

Normal python stuff is testable using the normal python testing mechanisms.  I
think given a way to easily fake up Http_requests and verify Http_responses /
parse HTML output I'd be happy with plain unit testing.  Checking the HTML
output could be as simple as

text, response = fake_publish(app_root, '/foo/bar/baz')
assert text.find(templates.db_record(test_db_entry)) != -1

Then I could use wget for a few high-level sanity checks.  Then all I need is
a script to automatically run all the tests on a staging area and if they pass
copy it over to the live site, and I'm happy :)