[MOBY-dev] CommonSubs.pm: complexResponse

[Pieter Neerincx]

On 22-Nov-2005, at 2:01 PM, Mark Wilkinson wrote:

> 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.

That's cool! I'm looking forward to test the tests :)

Pieter

>
> 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
>>
>>
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl