Implementation Policy Questions
Christian brenninkmeijer
I have been writing JUnit tests directly against the IDMapper interface
and this brought up a number of interesting policy questions.
Is there a defined standard for these cases or are both solutions
acceptable.
Set<Xref> mapID (Xref ref, DataSource... tgtDataSources)
Should ref be included in the result set?
If yes I assume only if ref's DataSource is in tgtDataSources
Set<Xref> mapID (Xref ref, DataSource... tgtDataSources)
If there are no mapped Xref should the result be null or an empty set?
Doc say it may not be null.
Map<Xref, Set<Xref>> mapID(Collection<Xref> srcXrefs, DataSource...
tgtDataSources)
Docs say this may not return null.
But must it return a set (possibly empty) for each Xref in srcXrefs?
Set<Xref> freeSearch (String text, int limit)
May this return null or must it always be an empty set?
(Assuming freeSearch is supported of course.)
Set<Xref> freeSearch (String text, int limit)
Is limit a hard requirement?
In other world if there are more than limit results may more results be
returned?
void close()
boolean isConnected()
If close() is called and then isConnected() must the result always be false?
or only if it make sense to close something?
PS.
I still have to work out how to get these Interface JUnit test working
in ANT across projects.
Should not be too hard I just haven't tried yet.
--
Christian Brenninkmeijer
University of Manchester
MyGrid team
Martijn van Iersel
I've tried to encode this type of assumptions using a unit test myself.
It's still a work in progress, but you can find it here:
http://svn.bigcat.unimaas.nl/bridgedb/trunk/benchmarking/test/org/bridgedb/benchmarking/Base.java,
Please take a look at that class first, because a lot of your questions
are answered in it. Of course I'll gladly look at remaining questions.
--
Martijn
Christian brenninkmeijer
Is there ever a logical case where an Xref should have either an Id or a
DataSource equal to null?
If so what is the logic for having Xrefs with nulls?
If yes than I will add tests to all methods that these do not case
exceptions.
However if there is no logical reason to allow either to be null than
the Xref constructor should fail fast and throw an IllegalArgumentException
On 12/03/2012 13:24, Martijn van Iersel wrote:
> Hi Christian
>
> I've tried to encode this type of assumptions using a unit test
> myself. It's still a work in progress, but you can find it here:
> http://svn.bigcat.unimaas.nl/bridgedb/trunk/benchmarking/test/org/bridgedb/benchmarking/Base.java,
In this work you do create Xrefs with nulls but is that the best approach?
Martijn van Iersel
Here is a reason. An editor (like e.g. PathVisio) may not be able to set
the id and DataSource at the same time. So when the user enters an id,
it creates an Xref with the DataSource set to null (or vice versa).
This may not seem like a very good reason. The trouble is, throwing an
IllegalArgumentException from the constructor breaks backwards
compatibility, and breaks existing tools. So if we do this at all, it
will have to wait for a major version update.
--
Martijn
Christian brenninkmeijer
>
> I've tried to encode this type of assumptions using a unit test
> myself. It's still a work in progress, but you can find it here:
> http://svn.bigcat.unimaas.nl/bridgedb/trunk/benchmarking/test/org/bridgedb/benchmarking/Base.java,
>
the Tests I am writing and will eventually ask to be included.
One question below answered the rest are still open. Where either may
well be the acceptable behaviour.
> Please take a look at that class first, because a lot of your
> questions are answered in it. Of course I'll gladly look at remaining
> questions.
>
> --
> Martijn
>
>
> On 12/03/12 12:01, Christian brenninkmeijer wrote:
>> Hi all (but especially Martijn who should reply)
>>
>> I have been writing JUnit tests directly against the IDMapper interface
>> and this brought up a number of interesting policy questions.
>> Is there a defined standard for these cases or are both solutions
>> acceptable.
>>
>> Set<Xref> mapID (Xref ref, DataSource... tgtDataSources)
>> Should ref be included in the result set?
>> If yes I assume only if ref's DataSource is in tgtDataSources
Still open
>>
>> Set<Xref> mapID (Xref ref, DataSource... tgtDataSources)
>> If there are no mapped Xref should the result be null or an empty set?
>> Doc say it may not be null.
Still open
>>
>> Map<Xref, Set<Xref>> mapID(Collection<Xref> srcXrefs, DataSource...
>> tgtDataSources)
>> Docs say this may not return null.
>> But must it return a set (possibly empty) for each Xref in srcXrefs?
Still open
>>
>> Set<Xref> freeSearch (String text, int limit)
>> May this return null or must it always be an empty set?
>> (Assuming freeSearch is supported of course.)
Still open
>>
>> Set<Xref> freeSearch (String text, int limit)
>> Is limit a hard requirement?
>> In other world if there are more than limit results may more results be
>> returned?
Still open
>>
>> void close()
>> boolean isConnected()
>> If close() is called and then isConnected() must the result always be
>> false?
>> or only if it make sense to close something?
Martijn tested it so after close() isConnected() MUST retun false.
Not sure why have set up the test accordingly.
>>
>> PS.
>> I still have to work out how to get these Interface JUnit test working
>> in ANT across projects.
>> Should not be too hard I just haven't tried yet.
>>
>
Christian Brenninkmeijer
> Hi Christian
>
> set the id and DataSource at the same time. So when the user enters an
> id, it creates an Xref with the DataSource set to null (or vice versa).
>
So the IDMapper should be able to deal with half nulls.
End of discussion.
I will add the approriate tests.
--
Christian Brenninkmeijer
Department of Computer Science
University of Manchester