Unit-Test Structure Submitted

All,

I have just submitted a first-cut at a unit-test harness. The unit-tests do require the use of the 'nose' python module.
Everything has been placed in the 'test' directory off of the root trunk branch. There is a README file with lots of information on
how to use it. This is in addition to a few test cases already bundled in (they make great examples)! The idea is that whenever
somebody adds a new feature or makes a change they update/add the appropriate test case and re-run the harness to make sure nothing
is broken.

There is most definitely room for improvement with this, but it gives a starting point from which discussions and modifications can
take place.

Any questions or comments?
--James Evans

All,

I have just submitted a first-cut at a unit-test harness. The unit-tests do require the use of the 'nose' python module.

[...]

Any questions or comments?

This is great, many thanks! I'd just suggest, if possible, adding a
top-level .test() function, so that the usual idiom for package
testing 'import foo;foo.test()' can be applied. I have a shell
function for that:

function pytest {
    # Run the test suite for a python package by name.
    # This assumes the package has a top-level .test() routine to run its
    # test suite.
    local pname=$1

    python -c "import $pname;${pname}.test()"
}

that I use for things like testing numpy or scipy easily:

uqbar[~]> pytest numpy
Running unit tests for numpy
[...]

···

On Wed, Feb 18, 2009 at 11:43 AM, James Evans <jrevans1@...310...> wrote:
----------------------------------------------------------------------
Ran 1931 tests in 4.999s

OK (KNOWNFAIL=1, SKIP=11)

Cheers,

f

What is the naming convention for the test harness? I see
filenames_with_underscores, camelCase, CapWords, and it looks like all the methods in MplTestCase are camelCase, whereas mpl uses only names_with_underscores. Although it would probably be a lot of busy work to convert at this point, I think it would be a good
idea to follow the existing mpl naming conventions.

Darren

···

On Wed, Feb 18, 2009 at 2:43 PM, James Evans <jrevans1@…55…310…> wrote:

All,

I have just submitted a first-cut at a unit-test harness. The unit-tests do require the use of the ‘nose’ python module.

Everything has been placed in the ‘test’ directory off of the root trunk branch. There is a README file with lots of information on

how to use it. This is in addition to a few test cases already bundled in (they make great examples)! The idea is that whenever

somebody adds a new feature or makes a change they update/add the appropriate test case and re-run the harness to make sure nothing

is broken.

There is most definitely room for improvement with this, but it gives a starting point from which discussions and modifications can

take place.

Any questions or comments?