[MOBY-dev] CommonSubs.pm: complexResponse

[Frank Gibbons]

At 08:01 AM 11/22/2005, you 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.

So Mark, if I understand correctly, it should first check to see if the 
user has defined those environment variables. That should indicate that the 
user does have a local registry. It should a local registry if available, 
but fall back to using MOBY Central  if it's not available. Right?

That'd be awsome!

-Frank


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

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