[NEW RELEASE] Test development helper library for SonarQube 1.0.0

[Michel Pawlak]

Hi,

I'm pleased to announce the first release of a small library aimed at helping testing code of custom SonarQube plugins.

Relase Notes:

• Assertion to check that a custom check does not raise issues when run against a test file
• Assertion to check that a custom check does raise expected issues when run against a test file
• Meaningful error messages (preconditions not met, expected issues that were not found, unexpected issues that were found, line and issue message) 

The objective of this first step was to provide a way to test custom JavaChecks without having to depend on sonar-java/java-checks' JavaCheckVerifier class, and provide assertions that explain better what went wrong when a test does not pass.

More information and usage information are available on the project's GitHub page.

Feedback would be appreciated !

Enjoy !

Michel

[Michel Pawlak]

Hi,

Update: there is a (small) bug in the non compliance comment parser in version 1.0.0. If the non compliance comment has trailing whitespaces, the comment won't be recognised. 

Example:

// Noncompliance {{Expected message}} <-- trailing comment there

The workaround is... to make sure that there is no trailing whitespace in non compliance comments (seems obvious). The bug is already fixed in branch 1.0.1 (not released yet).

@SonarSource team: could you please add the library to the "Other contributions" section of the Community Plugins page ? Thank you in advance.

Cheers,

Michel

[Michael Gumowski]

Hello Michel,

Sorry for the delay, we should have responded to you earlier.

You are a bit too fast for us on that subject. One of the goal of the current java sprint is to extract JavaCheckVerifier from the java-checks tests, and provide it in a much easier way. (https://jira.sonarsource.com/browse/SONARJAVA-1257)

You did a great job on your helper library, but unfortunately we won't add it to the "Other contributions" section of the Community Plugins page for the moment, as it will overlap with what we plan to do.

Regards,

Michael GUMOWSKI | SonarSource

Software Developer @ Language Team
http://sonarsource.com

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/e8153998-2a30-4df3-801d-66dccea64a65%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Michel Pawlak]

Hi again,

Well, the reason that led to the creation of this library whas not only due to the fact that the JavaCheckVerifier class was inside the java-checks artifact. The main reason was due to the fact that errors reported by JavaCheckVerifier are not really readable, and messages are often misleading. I wanted to ease the detection of what really needs to be fixed when a UT fails.

I see that you created your ticket two days ago while this thread was started 11 days ago ;-) Well if you want to write your own stuff that's fine with me. However you could also had posted comments and requests and let your community contribute.

Regards,

Michel

[Michael Gumowski]

Michel, indeed the JIRA ticket is pretty young (I created it when coming back from holidays, didn't saw your emails before). However, we have been discussing the subject for a few months internally.

Now, don't misunderstand us. We perfectly agree on the fact that the current JavaCheckVerifier can be improved (and it definitely should be!). Feedback on failing UTs is an essential part of it, especially when aiming improvements on how to test user custom rules. Extracting it from the tests of java-checks is a first step. You know that the java plugin is open source, and we will review any propositions/PR related to any improvement on that subject!

Moreover, having the JavaCheckVerifier exposed from within the java plugin in a much clearer way will also help us to standardize how to test rules. I'm sure you will understand that we would prefer to reinforce the plugin (with the help of the community!), rather than depends of small libraries outside our scope. Having such utility classes exposed also imply more visibility for them, and consequently more feedback, more contributions from the community!

Regards,

Michael GUMOWSKI | SonarSource

Software Developer @ Language Team
http://sonarsource.com

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/5b8d39e3-0cd9-4d9d-8475-40ad7b00a271%40googlegroups.com.

[Michel Pawlak]

Hi again Michael,

I think you misunderstand me. I informed the community that I made a helper library that can help people with testing their custom JavaChecks, especially when developing them in a TDD fashion and needing meaningful error messages. As far as I know, I'm not competing with an existing api. Therefor I asked you if it is possible to add a link to this library on the community plugins page. That's it.

That you want to expose your internal test helper class in an API and want to improve it over time is great, however, while I accept your decision of refusing my request, it is kind of difficult to understand that you refuse my request for the sole reason that you plan doing something similar in a near future. And to be clear I'm not asking SQ to use this "small library", but just let people know that a solution exists until you provide your own alternative.

Anyway, I'll continue using it myself :-)

Best regards,

Michel