GitLab

1. Since, like transcript() and unlike most getters, seq() potentially
triggers database lookups, put all its tests near transcript ones();

2. Make sure everything is prepared so that running test_getter_setter()
on seq() works in local-only mode;

3. Add a test checking for an exception being thrown in the event of
seq() neither having a local sequence nor being able to retrieve one
from the database;

4. Add an online test.

The first one verifies that the internal fetch method in RNAProductAdaptor
has correctly assigned a Transcript to the RNAProduct object it returns.
All transcript() itself does here is return the store assignment.

The second one tests on-demand retrieval of transcripts in transcript()
itself, via an appropriate method in TranscriptAdaptor.

First of all, actually pass a transcript object to test_getter_setter;
this was a mistake.

Secondly, due to the way test_getter_setter() works it is necessary to
either link the RNAProduct object to the database (or to be precise, set
an adaptor) or pre-set a Transcript object. I have chosen the latter
because that way this part of the tests remains local-only.

To quote Perl::Critic::Policy::Subroutines::ProhibitBuiltinHomonyms
documentation:

"It is reasonable to declare an object method with the same name as a Perl
built-in function, since they are easily distinguished from each other.
However, at this time, Perl::Critic cannot tell whether a subroutine is
static or an object method."

Since this *is* a method, we must simply quell the warning.

We *are* in fact unpacking @_ first here (modulo the definition of
$class in the middle, then again moving it down does not make perlcritic
happy), it's just that perlcritic does not understand the purpose of
rearrange(). Quell the warning.

By default, at severity 3 or higher perlcritic complains about _tables()
having been declared but not being used. In reality this method *is*
used but in the superclass Bio::EnsEMBL::DBSQL::BaseAdaptor (indeed, it
is declared as abstract over there so the code will not even work
without a concrete implementation in the subclass), unfortunately
perlcritic doesn't handle this. Therefore, we now tell it to relax this
policy for this specific subroutine.

This doesn't seem to have any negative effect on running this test suite
and it could in principle reduce the risk of cross-talk between suites
when the harness is used. Moreover, we could establish stronger separation
between local and database-backed tests by putting them in separate
packages.

At the same time, tell perlcritic not to complain that the package name
does not match the file name.

Toggling it has no effect on output verbosity in this test suite, I see no
mention of it anywhere in either TAP::Harness, Test::Simple or
Test::More documentation, and perlcritic complains about it.

If $stable_id is undef, a discrepancy exists in values returned by
stable_id() and stable_id_version(): the former returns an undef, the
latter returns "." or ".$version" (implying the stable-id part to be an
empty string) + throws a warning about using an undefined value in
concatenation. Have the constructor set $stable_id to an empty string if
no value has been passed so that we both get consistent answers and
quell the warning.

Transcript retrieval from the database will be implemented once we have
defined TranscriptAdaptor::fetch_by_rnaproduct_id(), for now attempting to
invoke this bit produces an "unimplemented" warning.

Sequence retrieval from the associated Transcript object will be
implemented once we have in fact got RNAProduct linked to Transcript and
having decided how much of Translation::seq() logic we require in this
case, for now attempting to invoke this bit produces an "unimplemented"
warning.

1. See if the constructor correctly assigns its arguments (sans adaptor)
   to appropriate member variables
2. Check if the default version number is 1
3. A basic set of setter/getter tests

At this point the only reason for the current set of tests still failing
should be - and unless I have misread the output, it is - that there is
still no rnaproduct table in the database. Will get to that bit shortly.

Nb. it uses the same kind of reimplementation of the internal function
_list_dbIDs() as TranslationAdaptor so that multi-species scenarios
are handled correctly.

At the moment all that is tested is whether the two classes have been
defined, whether it is possible to instantiate respective objects, and
whether RNAProductAdaptor has been registered with Core DBAdaptor.
Needless to say all of these tests fail for now.

Deprecation of DBFile and Utils/Collector.pm

Necessary Updates to the Mapper code [ENSCORESW-2168].