Steven Knight wrote:

> > > > Furthermore, I have added a mechanism for testing. Both for testing
> > > > individual modules and executing recipes. The typeless nature of Python
> > > > requires doing a lot of tests. Only a few have been added so far, but
> > > > one bug has already been detected.
>
> I'd highly recommend implementing a testing discipline in your process
> up front. On SCons, we have a policy (adopted from and enforced by
> Aegis) that every checkin must be accompanied by one or more new or
> changed tests that demonstrate the bug or feature by failing on the old
> code base. By building up our tests incrementally, we now have a very
> complete set of unit tests for our modules, and a regression test suite
> of 163 end-to-end tests.
>
> I've found this way of working to be especially crucial during the early
> stages of development, when you may need to refactor parts of the design
> frequently as you add features. Being able to do this and *know* you
> haven't broken anything because all of the tests pass (a la eXtreme
> Programming) is invaluable.

Although I agree with doing a lot of testing, A-A-P is still in a phase
where the design is more important than correct code. The main goal
currently is to quickly get to a stable recipe format and find good
interfaces between modules. This means I do want to find bugs that
influence the design, but don't care much for details. Actually, I
should use tests that check if the specifications are right. That means
using real-life test cases.

> Python will throw an exception if you try to use a function that hasn't
> been imported. It won't throw an exception just because you pass a
> variable of the wrong type, but it will if/when you try to use that
> variable inappropriately.

Thus this basically means the tests must cause every function to be used
at least once, so that an exception will be thrown when it wasn't
imported. Would require a coverage checker to check if the tests really
did this.

> In practice, we've found that the ongoing challenge is to not just rely
> on generic exception-handling, which is great for programmer debugging,
> but to catch exceptions at all of the appropriate points and provide
> error messages more helpful for less sophisticated end-users.

That's something I'm doing already, since it greatly helps quickly
locating a problem. A try/except block around every function that can
throw an IOError, for example.

> > Perhaps some kind of Python-lint exists, I haven't looked for it yet.
>
> Look for PyChecker, available on SourceForge. It finds a number of
> problems in Python code by performing analysis on the compiled byte
> code.

I'll have a look at it later.

--
CRONE: Who sent you?
ARTHUR: The Knights Who Say Ni!
CRONE: Aaaagh! (she looks around in rear) No! We have no shrubberies here.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
/// Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim \\\
\\\ Project leader for A-A-P -- http://www.a-a-p.org ///
\\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///