Improve test coverage - currently 49.5% in bio-java core

[richarda23]

Test coverage is little low - covering more code would enable

• more confident refactoring. In a code-base with contributions over a long period of time there are cases where new language features can replace existing code in perhaps a more reliable way, but without tests it's sometimes hard to be sure
• greater confidence in the existing functionality
• self-documentation of methods
• identifying obsolete or unused code which could perhaps be scheduled for removal or marked deprecated?

Like covid vaccination rates 100% is unachievable but 50% is a bit on the low side, especially for a library project.
Making sure all public methods are invoked in test code would be a start, and it could be incremental.
I'll attach a PR adding some tests for some utility methods which identified 1 bug to get the ball rolling...

[josemduarte]

Thanks @richarda23 . Totally agree, this has been an eternal pending issue for this project. More test coverage is badly needed.

One curiosity. How did you measure coverage?

I actually setup SonarCloud for biojava sometime ago (which does coverage too), but I'm not sure if that's accessible to everyone.

[richarda23]

For this, I just manually ran EclEmma which is an Eclipse plugin (I'm not sure if it's actually maintained any longer), but I expect most tools give similar information.

[richarda23]

Latest values are 75% class, 56% method, 58% line - so some improvement. Will try to add more tests to at least touch uncovered non-trivial classes

[josemduarte]

That's great news. Thanks @richarda23 . FYI I did set up Sonarqube cloud in CI. But I think test coverage reporting is somehow not working.

Anyway if you are interested the Sonarqube reports are available here: https://sonarcloud.io/organizations/biojava/projects . Let me know if you can't access that and I'll see how to add accounts.

[richarda23]

Thanks Jose, I can see Sonarqube results fine. I'm tackling some classes now in biojava-core o.b.n.core.sequence package (ChromosomeSequence, ExonSequence etc) as some of these aren't covered by tests.
I've come across quite a few issues with some of the classes that I would consider bugs, for example:

• equals and hashcode throwing NullPointer exceptions as some of the properties used by equals() in AbstractSequence aren't set
• calculation of intron sequences on negative strands returns unexpected results in GeneSequence
• collections of subelements aren't encapsulated
  What would you advise? I can raise a PR with the tests I've written, with those failing ones marked @disabled for discussion, or raise what I think are issues.

[josemduarte]

That sounds like a good plan @richarda23 . Let's start a discussion based on a PR.