[MOBY-dev] CommonSubs.pm: complexResponse

[Mark Wilkinson]

I just changed the code on my own t/* to use environment variables while 
I was on the plane yesterday so that I could run tests on my own Windows 
installation - funny that we were all looking at the same piece of code 
at the same time :-)

i'll commit these changes as soon as I have double-checked them.  In 
general it will allow you to test your local registry instead of the 
remote one by default.

M



Frank Gibbons wrote:

> 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
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
>