[MOBY-dev] CommonSubs.pm: complexResponse

[Frank Gibbons]

Congratulations, Pieter,

At 08:32 AM 11/21/2005, you wrote:
>One more thing. After my changes I tried make test and noticed that
>the Config.t is skipped, because it's only required for a local
>BioMOBY Central..., but I do have one and I have set my
>MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very
>familiar with the test scripts...

I think you just got yourself nominated to be caretaker of the test 
t/Config.t. I don't have a local registry, so there was no way for me to 
test its operation. Most users (I think) are in the same position, so this 
test is skipped by default.

For details on how to use the testing framework, you could look at  the 
Perl modules Test::Simple and Test:More. The basic idea is that you execute 
some MOBY code for which you believe you know the output. You compare 
actual output to expected output using the is() function. It generates 
errors if the two don't match. You can also check for correct failure using 
isnt(), which generates a similar error. Examples might be:

is(2+2, 4, "Can't do addition");' # Generates error with this string 
showing up on output device
is(scalar @A, $#A + 1, "Scalar gives incorrect results");

Generally, tests should be symbolic, rather than specific. This leads to 
tests that are more easy to maintain over time: if an array is built before 
it is tested, and if it's tested symbolically, it should be possible to 
alter the array contents at a later point, without breaking that test. Take 
a look in the Client-Central.t for examples of this: a registration 
structure is created, services are registered, then the registration object 
is itself queried, and the results compared symbolically with the original 
data. This verifies that the information flows through the system 
correctly. If someone later decides to change a small detail (e.g., a 
parameter name), the tests should continue to pass without modification.

But the tests themselves don't really have to complicated to be useful: 
check that each module exports the functions it claims to implement, check 
that set/get methods work correctly, check return types in all contexts 
(does it return array in list context, scalar in scalar context). All that 
stuff is important in maintaining a coherent interface over time. It also 
helps to find inconsistencies.

I think it would be really great if you could build some useful, robust, 
portable tests for the local-registry configuration. This kind of test can 
be a big help to users trying to install their local registry, so its 
utility goes beyond merely regression testing the code, it's also useful to 
debugging local installations with perfectly functioning code.

-Frank

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons