any unit test result referring to any scala test class (using scalatest) won't show in the sonar

[kknd22]

I have issue for sonar to understand the test result from scalatest. And I found the following reference.
Do you have answer for it? For me, code coverage is fine the problem is only for unit test result from the test-results directory, where contains the result *.xml files. If the xml refer to a java class then is fine. If it points to a scalatest file then it won't show up.

How to make SonarQube analyzing SBT projects (with Java and Scala) and importing code coverage & unit test coverage?

Thanks
-cl

[hcoles]

The scalastyle plugin doesn't do anything with test results - it's narrowly focussed on running scalastyle.

We'd prefer not to make this into a general Scala plugin, but as one doesn't currently exist we're happy to accept pull requests here until there's enough non scala style functionality for it to be moved out elsewhere (see #7)

That said, I'm not clear on what is involved in getting this to work. The issue might only be fixable in whichever plugin is currently responsible for reading that XML file.

[maiflai]

I think this relates to maiflai/gradle-scalatest#29. The underlying problem seems to be that the SurefireSensor expects Java source files, not Scala.

It seems appropriate to create a ScalaTest plugin?

[kknd22]

thanks Stu.
It looks like groovy community has similar problem, maybe we can use similar approach to solve the issue?

http://grepcode.com/file/repo1.maven.org/maven2/org.codehaus.sonar-plugins/sonar-groovy-plugin/0.6/org/sonar/plugins/groovy/surefire/SurefireSensor.java#SurefireSensor

-cl

[maiflai]

Yes, it looks like they have forked the Java implementation. Sadly this looks like a lot of copy-paste.

[kknd22]

I am looking at if using the similar approach, how much effort is it for scala... anyone else have a general feelings on this?

[maiflai]

"It depends".

I think that the Groovy implementation only works for tests which are defined in a file with a name which matches their classname. Groovy doesn't actually require this, so there is an opportunity for the reported metrics to be wrong. Scala has a similarly loose approach to source files.

I think it might be possible to supply a dummy InputFile rather than dropping the tests for which no source can be found.

It doesn't look like much work to implement a simple JUnit parser and SonarQube writer; the java and groovy plugins look complicated because they combine multiple analysers.