I'm scared to see what our coverage is o_o

quick status update: there are a few problems with this

• log files length > 4 MB cause Travis to be unhappy
• cobertura plugin has problems with MMCifFileTools.java
  (I suspect with getFields(Class<?> c)
• when running locally, problems with SymmetryTools.getQuaternarySymmetry(CeSymmResult) (stream operation on collections causing problems?)

running mvn cobertura:cobertura coveralls:report from command line currently fails with:

Build error: Line number 91 is greater than the source file biojava-structure/src/main/java/demo/DemoFATCAT.java size -> [Help 1]

I'm guessing that comes from the fact that we have two demo.DemoFATCAT classes. The one from biojava-structure has 87 lines, while biojava-structure-gui has 101.

With the latest commits on my branch, I could complete a run. Results should show up here soon https://coveralls.io/jobs/17327290

I don't see an immediate work around to the problem of the long-log file. This is an issue with Travis: travis-ci/travis-ci#3865

For now, #555 allows users to run the coverage reports locally. We can come back to this once the Travis issue can be addressed.

Btw: currently we have about 38% code coverage.

Andreas,
If the log file is configured using a rolling appender, you should be able
to skirt the file size issue.

Mark

On Aug 16, 2016 2:21 PM, "Andreas Prlic" notifications@github.com wrote:

Btw: currently we have about 38% code coverage.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#561 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABOqRylwSH2Eipl571BUSe_GwrVKYNOZks5qginIgaJpZM4JkHn9
.

so, the problem is not to run this locally, but using the travis-ci engine at https://travis-ci.org/biojava/biojava . This service terminates a build if the log is too long. If I configure a rolling appender, that would influence my local builds, but it would not change the behavior of travis-ci. Do I understand that correctly?

A possible easy fix for the too-long log problem is to switch the logging level to warn for travis. In any case going forward we should really try to cut the verbosity of some of the tests.

Hi Andreas,
Changing the log level would help, as would not dumping out sequences. :-)
I assume that every module has its own test log; if not, that might help as
well. Setting the rolling appender size would further reduce the log size,
by causing the log to roll over to another file whenever it reaches a
predefined limit. You end up with a series of log files (test.log.0,
test.log.1, etc).

Hope this helps,

Mark

On Wed, Aug 17, 2016 at 2:22 AM, Jose Manuel Duarte <
notifications@github.com> wrote:

A possible easy fix for the too-long log problem is to switch the logging
level to warn for travis. In any case going forward we should really try to
cut the verbosity of some of the tests.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#561 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABOqR_HI3C4Z8LshszpkOVEns4X-0BlZks5qgtLggaJpZM4JkHn9
.

working on reducing verbosity of unit tests. See #555

Why do not use Atlassian Clover?

A powerful code coverage tool supporting 20+ metrics. Here is a nice Clover/Cobertura comparison.

And it's for free for open source projects https://www.atlassian.com/software/clover/pricing.

BTW: We can set a static code analysis tool on top of that for example SonarQube aggregating additional code quality information.

I'd prefer a solution that works on the GitHub ecosystem.

@andreasprlic

Atlassian products are very powerful but I agree that it is better to choose a solution that works on the GitHub ecosystem.

Yes they are, I am using many of them in my daily work.

SonarQube (mentioned in #789) should be a good tool for coverage and for many other quality controls. They provide github integration with their cloud service for free for open source projects.