[moby] Re: [MOBY-dev] CommonSubs.pm: complexResponse

Wed Nov 23 22:20:14 UTC 2005

Hi everybody,
	I have installed many Perl packages, and many of them show lots of 
information when it is done the next invokation:

make TEST_VERBOSE=1 test

For instance, DBI uses Test::More inside its tests.

	Best Regards,
		José María

Frank Gibbons wrote:
> Mark,
> 
> Just ran the tests. Looks good, except the informational message is 
> somewhat jarring... ideally, the only output that appears is a series of 
> test-file names, with "..........ok" after them. I wonder if developers 
> need to see that message each time they run the tests - perhaps it would 
> help just as well if it were embedded as comments? What do you think?
> 
> I'll be gone for a few days, as it Thanksgiving down here.
> 
> -Frank
> 
> At 04:05 PM 11/23/2005, you wrote:
> 
>> On Wed, 2005-11-23 at 10:01 -0500, Frank Gibbons wrote:
>>
>> > 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.
>>
>> Not necessarily local - the environment variables are simply a way of
>> specifying which MOBY Central you wish to talk to by default (i.e. when
>> you don't initialize the MOBY::Client::Central object with a
>> "Registries" parameter).
>>
>> The following statements describe what happens:
>>
>> 1)  The MOBY::Client::Central module is hard-coded to default to
>> mobycentral.icapture.ubc.ca  as it's default registry
>>
>> 2)  When it is initializing, it first checks for the MOBY_SERVER and
>> MOBY_URI environment variables and uses those instead of the defaults if
>> they exist, otherwise it will default.
>>
>> 3)  Initializing MOBY::Client::Central using the "Registries" argument
>> will over-ride both of the previous behaviours
>>         -> use of this argument also allows you to interact with more 
>> than one
>> registry at a time (for **read-only** interactions) ...(note that this
>> latter behaviour has never been adequately tested, since it has never
>> been used AFAIK)
>>
>>
>>
>> >  It should a local registry if available,
>> > but fall back to using MOBY Central  if it's not available. Right?
>>
>>
>> yup.  That behaviour has always been true, actually; however the test
>> harness was hard coded to use the 'Registries' argument when it started-
>> up, so it was over-riding the useful behaviour that
>> MOBY::Client::Central already had :-)
>>
>> The same behaviour is now true for MOBY::Client::OntologyServer - it
>> will first check the environment variable, and if it isn't set, then it
>> will default to call home to mobycentral.icapture.ubc.ca
>>
>> Cheers!
>>
>> M
>>
>>
>>
>>
>> > 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
>> >
>> > _______________________________________________
>> > MOBY-dev mailing list
>> > MOBY-dev at biomoby.org
>> > http://www.biomoby.org/mailman/listinfo/moby-dev
>> -- 
>> "Ontologists do it with the edges!"
>>
>> Mark Wilkinson
>> Asst. Professor
>> Dept. of Medical Genetics
>> University of British Columbia
>> PI in Bioinformatics
>> iCAPTURE Centre
>> St. Paul's Hospital
>> Rm. 166, 1081 Burrard St.
>> Vancouver, BC, V6Z 1Y6
>> tel: 604 682 2344 x62129
>> fax: 604 806 9274
>>
>> _______________________________________________
>> 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
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
> 
> 

-- 
José María Fernández González		e-mail: jmfernandez at cnb.uam.es
Tlfn:	(+34) 91 585 54 50		Fax:	(+34) 91 585 45 06
Grupo de Diseño de Proteinas		Protein Design Group
Centro Nacional de Biotecnología	National Center of Biotechnology
C.P.: 28049				Zip Code: 28049
C/. Darwin nº 3 (Campus Cantoblanco, U. Autónoma), Madrid (Spain)