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

Frank Gibbons francis_gibbons at hms.harvard.edu
Wed Nov 23 21:49:15 UTC 2005


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 




More information about the MOBY-dev mailing list