JUnit report sensor #143

mwz · 2018-12-20T21:27:51Z

Initial implementation of the JUnit XML report sensor.
Unit tests and some minor refactoring is still left to do on this PR.

Example result of scanning sonar-scala:

Implements #32.

BalmungSan · 2018-12-21T02:51:16Z

src/main/scala/com/mwz/sonar/scala/junit/JUnitSensor.scala

+  override def describe(descriptor: SensorDescriptor): Unit = {
+    descriptor
+      .name(SensorName)
+      .onlyOnLanguage(Scala.LanguageKey)


I believe this sensor only works for test files.
Thus, you may add
.onlyOnFileType(InputFile.Type.TEST)

yes definitely

BalmungSan · 2018-12-21T02:53:13Z

src/main/scala/com/mwz/sonar/scala/junit/JUnitSensor.scala

+
+    val directories: List[File] =
+      reports.flatMap(path => Try(pathResolver.relativeFile(fs.baseDir, path.toString)).toOption)
+    // TODO: Is the injected fileSystem different from context.fileSystem?


To be honest, I had the same question before...
I don't remember why, but I ended up using the context one - I believe it was only to avoid dependency injection.

I'll find this out, but if it turns out it's the same then I think it's easier to just inject it instead of accessing it via the context or extracting it into a local value - but it's not a big difference though.

BalmungSan · 2018-12-21T02:57:46Z

src/main/scala/com/mwz/sonar/scala/junit/JUnitReportParser.scala

+              .asScala
+
+          // Collect the first file here.
+          files.headOption.flatMap(file => reports.headOption.map((file, _)))


Given you only care for the first file... - maybe, because it only makes sense that it matches just one file
Shouldn't you log a warning if more than one file is matched and also if any file is matched?
BTW, this reminds me #64 we may try to do this in a standardized way for all module.

Shouldn't you log a warning if more than one file is matched

That's something I thought about improving, although we're using fully qualified names combined with the tests folders which should result in unique files, so I'm not worried too much about this.

The reason why I'm using inputFiles instead of a single inputFile is to avoid catching exceptions if the file is not found, but actually, now I think that it would probably be more useful to do it that way and log an error if an expected file is not found.

BTW, this reminds me #64 we may try to do this in a standardised way for all module.

Agreed, I think we have been doing this in a wrong way using the cwd which leads to a whole load of path issues like, e.g. those discussed in #122. Using the FileSystem and PathResolver is the right way to go about this.

Cool, so if everything goes right we may replace our old attempts with the new resolve helper method.
Probably work for another PR (on which we should be sure to test all reported issues).

BalmungSan · 2018-12-21T03:02:11Z

src/main/scala/com/mwz/sonar/scala/util/Log.scala

+  def apply[T](clazz: Class[T], module: String): Log = Log(clazz, Some(module))
+  def apply[T](clazz: Class[T], module: Option[String] = None): Log = {
+    val log: Logger = Loggers.get(clazz)
+    val prefix: String = "sonar-scala" + module.map("-" + _).getOrElse("")


What about

val prefix: String = s"sonar-scala${module.fold("")("-" + _)}"

yes, that's much nicer - thanks

BalmungSan · 2018-12-21T03:04:29Z

src/main/scala/com/mwz/sonar/scala/util/util.scala

+  /**
+   * Save a new measure for the given metric.
+   */
+  def save[T <: java.io.Serializable](


You may use this helper in the ScoverageSensor too.

I'll roll this out across the other modules, but I'd prefer to do this in a separate pr.

BalmungSan · 2018-12-22T01:21:59Z

src/main/scala/com/mwz/sonar/scala/junit/JUnitSensor.scala

@@ -46,39 +48,52 @@ final class JUnitSensor(
    descriptor
      .name(SensorName)
      .onlyOnLanguage(Scala.LanguageKey)
+      .onlyOnFileType(InputFile.Type.TEST)
+    // TODO: Add a flag to disable the sensor.


// TODO: Add a flag to disable the sensor.

👍

BalmungSan · 2018-12-22T01:27:33Z

src/main/scala/com/mwz/sonar/scala/util/util.scala

@@ -27,7 +28,8 @@ import org.sonar.api.batch.measure.Metric
 import org.sonar.api.batch.sensor.SensorContext
 import org.sonar.api.config.Configuration

-import scala.language.implicitConversions
+import scala.language.{higherKinds, implicitConversions}


Where/Why exactly do we need higherKinds here ?

BalmungSan · 2018-12-22T21:34:53Z

src/main/scala/com/mwz/sonar/scala/util/syntax/SensorContext.scala

+    new SensorContextOps(context)
+}
+
+final class SensorContextOps(val context: SensorContext) extends AnyVal {


Why using an implicit conversion, instead of an implicit class?
The same goes to all syntax classes...

Also, what about having just one syntax.scala file with a object syntax { ... } and put there all the syntax helper classes?

I've tried to achieve something similar to how the syntax package is structured in cats (see an example here), but what I haven't done yet was to put everything into the package object, but I 'll do this soon (example) - I think it's a nice way to organise implicit conversions.

Why using an implicit conversion, instead of an implicit class?

I think that implicit classes get compiled to an implicit function and a class, it's syntax sugar, so perhaps it was done that way in cats to optimise compile times? That's the only reason I can think of.

"I've tried to achieve something similar to how the syntax package is structured in cats"

Oh, that would be nice - I assume we won't have an all shortcut.

"I think that implicit classes get compiled to an implicit function and a class, it's syntax sugar".

I am almost sure that is correct, but it would allow us to omit the import scala.language.implicitConversions
Also, I have the impression that is the recommendation to use implicit classes over implicit conversions - but can't find nothing related to that, maybe I just heard about it on a conference.

"so perhaps it was done that way in cats to optimise compile times?"

No idea...
Maybe we should ask to the very sage wizards for clarification? 🤔

Oh, that would be nice - I assume we won't have an all shortcut.

Yes, that's right - even though it's useful (and lazy!), my preference is to be more conscious about which implicit conversions I have in the scope, so I'll stay away from all 😆

I am almost sure that is correct, but it would allow us to omit the import scala.language.implicitConversions
Also, I have the impression that is the recommendation to use implicit classes over implicit conversions - but can't find nothing related to that, maybe I just heard about it on a conference.

This sounds sensible, and I'm happy with making that change unless we can find any evidence strongly supporting implicit conversions. I'll also try to dig a bit deeper and see if I can find anything more about it.

Thanks for your valuable feedback! 👍

It turns out that a value class cannot be a member of another class (trait), so if we want to have this nice structure with individual syntax traits instantiated in the package object, we need to keep the implicit conversions in those traits and have the classes sitting outside. I'll push those changes for now but feel free to propose an alternative way of doing this.

"It turns out that a value class cannot be a member of another class (trait)".

Oh, that explains it all.

Well, to be honest I think the only reason in Cats they use traits is to be able to combine them all in the all shortcut.
Since we don't plan to do that, we may leave them as objects and use implicit classes.

But at the end, there wouldn't be too much difference, so I will just leave it to your personal preference 👍

BalmungSan · 2018-12-22T21:59:38Z

src/main/scala/com/mwz/sonar/scala/util/util.scala


 /**
 *  Scala.Option <-> Java.Optional conversions.
 *  @note Taken from https://gist.github.com/julienroubieu/fbb7e1467ab44203a09f.
 */
 object JavaOptionals {
-  implicit def toRichOption[T >: Null](opt: Option[T]): RichOption[T] = new RichOption[T](opt)
-  implicit def toRichOptional[T](optional: Optional[T]): RichOptional[T] = new RichOptional[T](optional)
+  implicit final def toRichOption[T >: Null](opt: Option[T]): RichOption[T] =


Since the method is part of an object and an object is already final...
marking a def final is not redundant? - or does it help the JIT inlining or something like that?

This should be a trait (as per the examples above), but I haven't finished refactoring everything yet 😄

Oh that makes sense.

BalmungSan · 2018-12-22T22:07:00Z

src/main/scala/com/mwz/sonar/scala/util/util.scala

 }

 /** Transform this Option to an equivalent Java Optional */
-class RichOption[T >: Null](opt: Option[T]) {
+final class RichOption[T >: Null](val opt: Option[T]) extends AnyVal {


👍 for making this a value class - (I believe I was the one that first coded this, so thanks for improving it)
And again, why don't make this an implicit class instead of using implicit conversions?

Also, I think this counts as syntax too. Thus, we should move them to the syntax object/package and rename them OptionOps and OptionalOps just to be consistent.

👍 for making this a value class - (I believe I was the one that first coded this, so thanks for improving it)

👍

I think that I addressed the first part of your comment above, but regarding those option conversions I didn't want to refactor too much at once and tried to touch as little as possible that affects other modules, so, for now, I might only add a TODO to refactor this later or possibly in a separate PR.

mwz · 2018-12-23T17:32:49Z

I've also refactored the optional conversions. Almost finished, but still have some more tests to write.

mwz · 2018-12-24T22:53:30Z

Ok, I'm finished - I also updated all of the examples projects with the junit settings required to get this to work. I'll open a separate PR with an updated readme and release notes in a separate PR once this is merged.

I'd appreciate if you could have another look @BalmungSan.

…thout ‘sonar.tests’)

BalmungSan · 2018-12-25T18:20:03Z

src/test/scala/com/mwz/sonar/scala/util/syntax/SonarConfigSpec.scala

@@ -31,12 +31,13 @@ class SonarConfigSpec extends FlatSpec with Matchers {
    val conf = new MapSettings()
      .setProperty("path", "this/is/a/path, another/path")
      .asConfig()
+    val defaultPath = List(Paths.get("default/path"), Paths.get("default/path2"))


Just one minor thing, this should be called defaultPaths (since now there are many).

yes of course, I'll fix that

BalmungSan · 2018-12-25T18:40:00Z

"I'd appreciate if you could have another look @BalmungSan."

I have been reviewing as you pushed, I just haven't commented anything because I saw everything O.K. 👍

Just one thing, why did you remove the disable property?
I just read that the sensor needs the sonar.tests property. But anyways I still think it makes sense to have the disable property. For example I have the sonar.tests property in my projects, but I don't plan to use this module.

Also, we must not forget to apply some of the changes we have discussed here to other parts of the project. I don't know if you want to to that before or after the new release.

BTW, Happy holidays 🎉

mwz · 2018-12-26T22:53:12Z

I have been reviewing as you pushed, I just haven't commented anything because I saw everything O.K. 👍

Cool, thanks!

Just one thing, why did you remove the disable property?

I came to the conclusion that there is no need to allow users to explicitly control when to disable this sensor because 1. the sensor won't run if you don't specify the sonar.tests property, 2. if you define it, but not for Scala tests (e.g. just for Java), then the sensor won't find any Scala test files and it won't save any metrics, so in my opinion, there is no need to for this flag. The same effect can be achieved by simply not configuring the sensor correctly, i.e. not changing any of your existing scanner properties.

Also, we must not forget to apply some of the changes we have discussed here to other parts of the project. I don't know if you want to to that before or after the new release.

I don't want to delay the release too much, so I'll do this afterwards. I have some nice features planned in the pipeline, so there will be a little bit of refactoring this and early next year :)

BTW, Happy holidays 🎉

Happy holidays to you too!

mwz added 5 commits December 19, 2018 22:19

WIP Unit tests sensor.

40f6c3b

Tweak debug messages.

00f8a1e

Save test metrics.

657983a

Renamed the sensor; improved logging.

f019abe

Update log tests.

a21ffd5

mwz mentioned this pull request Dec 20, 2018

Scala Test Count is not reported #32

Closed

BalmungSan reviewed Dec 21, 2018

View reviewed changes

mwz added 5 commits December 21, 2018 18:20

Address some PR comments.

6a57a7a

Minor refactoring of file resolution.

ce6ecf8

Improved logging.

06964ad

Improve logging.

34dfb6b

Update logic for filtering junit report files.

bf3686c

BalmungSan reviewed Dec 22, 2018

View reviewed changes

mwz added 4 commits December 22, 2018 12:16

Refactor utils.

ca4a468

Refactor utils.

7c5e8cd

Add config syntax tests.

51aa893

Add some sensor tests.

6644a75

BalmungSan reviewed Dec 22, 2018

View reviewed changes

mwz added 5 commits December 22, 2018 23:30

Add file system syntax tests.

c8d9884

Add sensor context syntax tests.

4903118

Add a syntax package object.

79634e0

Refactor syntax into implicit classes.

76ba759

Refactor option conversions.

dd0446f

Add a new file system test.

08cf5b6

mwz added 10 commits December 23, 2018 21:05

More sensor tests.

1ec5cc5

Report parser tests.

50e6a5d

Remove a trailing comma.

8d4f1c8

Change logging level.

3a5f129

Add sonar.tests property to the example set projects.

bd2e976

Make tweaks to filtering of junit files.

e58775f

Make parsing junit reports safer.

5c4d653

Update example mvn projects.

4607cef

Update example grade projects.

036d17e

Use getStringArray to get a list of paths from the config.

2df6b1c

mwz changed the title ~~WIP JUnit report sensor~~ JUnit report sensor Dec 24, 2018

Drop the ’sonar.junit.disable’ property (the sensor isn’t executed wi…

b1411d7

…thout ‘sonar.tests’)

BalmungSan reviewed Dec 25, 2018

View reviewed changes

Rename defaultPath to DefaultPaths.

e6c9f0f

mwz merged commit 9cd167e into master Dec 28, 2018

mwz deleted the unit-tests-sensor branch December 28, 2018 13:51

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

JUnit report sensor #143

JUnit report sensor #143

mwz commented Dec 20, 2018

BalmungSan Dec 21, 2018

mwz Dec 21, 2018

BalmungSan Dec 21, 2018

mwz Dec 21, 2018

BalmungSan Dec 21, 2018

mwz Dec 21, 2018

mwz Dec 21, 2018

BalmungSan Dec 22, 2018

BalmungSan Dec 21, 2018

mwz Dec 21, 2018

BalmungSan Dec 21, 2018

mwz Dec 21, 2018

BalmungSan Dec 22, 2018 •

edited

BalmungSan Dec 22, 2018

BalmungSan Dec 22, 2018 •

edited

mwz Dec 22, 2018

BalmungSan Dec 23, 2018 •

edited

mwz Dec 23, 2018

mwz Dec 23, 2018

BalmungSan Dec 23, 2018

BalmungSan Dec 22, 2018

mwz Dec 22, 2018

BalmungSan Dec 23, 2018

BalmungSan Dec 22, 2018

mwz Dec 22, 2018

mwz commented Dec 23, 2018

mwz commented Dec 24, 2018

BalmungSan Dec 25, 2018

mwz Dec 25, 2018

BalmungSan commented Dec 25, 2018

mwz commented Dec 26, 2018 •

edited

JUnit report sensor #143

JUnit report sensor #143

Conversation

mwz commented Dec 20, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BalmungSan Dec 22, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BalmungSan Dec 22, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BalmungSan Dec 23, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mwz commented Dec 23, 2018

mwz commented Dec 24, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BalmungSan commented Dec 25, 2018

mwz commented Dec 26, 2018 • edited

BalmungSan Dec 22, 2018 •

edited

BalmungSan Dec 22, 2018 •

edited

BalmungSan Dec 23, 2018 •

edited

mwz commented Dec 26, 2018 •

edited