[MOBY-dev] CommonSubs.pm: complexResponse

[Mark Wilkinson]

Hmmmm... there's still a dependency on the public ontologyserver 
though... and therefore a dependency on having a network connection.  I 
remember now that this is somethign I wanted to fix a couple of months 
ago but it got pushed down my TO DO list in favor of keeping my job ;-)

I'll try to fix that today - it will make the PlaNet people happy as 
well!   :-)

M



Pieter Neerincx wrote:

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