How can I registermy custom checks for unit tests with java plugin 3.2 ?

[Michel Pawlak]

Hi folks,

I'm trying to register our checks (on test code) but I'm stuck. I have a CheckRegistrar Implementation that overrides register(final RegistrarContext registrarContext) as follows :

    @Override
    public void register(final RegistrarContext registrarContext) {
        registrarContext.registerClassesForRepository(CAPBSJavaRulesDefinition.REPOSITORY_KEY, getCheckClasses());
    }

The method getCheckClasses returns all my custom checks. All are then accessible / addable to a profile from the UI. But do not seem to be executed on test code. What am I missing ?

Thanks in advance for your help.

Michel

[Nicolas Peru]

Hi Michel, 

Executing custom rules on test code is not supported for the moment. I am sorry to let you know that this is a known limitation but not something we plan to work on for the moment. 

Cheers,

2015-05-01 15:28 GMT+02:00 Michel Pawlak <[hidden email]>:

Hi folks,

I'm trying to register our checks (on test code) but I'm stuck. I have a
CheckRegistrar Implementation that overrides register(final RegistrarContext
registrarContext) as follows :

    @Override
    public void register(final RegistrarContext registrarContext) {

registrarContext.registerClassesForRepository(CAPBSJavaRulesDefinition.REPOSITORY_KEY,
getCheckClasses());
    }

The method getCheckClasses returns all my custom checks. All are then
accessible / addable to a profile from the UI. But do not seem to be
executed on test code. What am I missing ?

Thanks in advance for your help.

Michel



--
View this message in context: http://sonarqube.15.x6.nabble.com/How-can-I-registermy-custom-checks-for-unit-tests-with-java-plugin-3-2-tp5034913.html
Sent from the SonarQube Developers mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Michel Pawlak]

Hi Nicolas, thanks for your reply. I must admit that this is not a good news :-(

Here is a (small) subset of the checks I have already developed / or plan to develop :

- IgnoredTestWithValidDocumentationCheck (INFO, is triggered if message matches a given regexp, in our case it means that a JIRA ticket is provided)
- IgnoredTestWithNoDocumentationCheck (BLOCKER, @Ignore or @Ignore("") should never be used)
- IgnoredTestWithBadDocumentationCheck (BLOCKER, is triggered if message does not match a given regexp, in our case it means that no JIRA ticket is provided, which in turn means that we are pretty sure that nobody will fix the test later)
- MissingAssertionCheck (MAJOR, includes a large set of assertion methods such as junit assertions but also assertj assertions, mockito verify, powermockito, etc.)
- PoorlyNamedTestMethodCheck (CRITICAL, triggered if a test method name does not match a regexp. we prefer to have well self documented test method names rather than documented assertions)
- TooManyAssertionsCheck (MAJOR, soft assertions should be used instead of multiple blocking assertions which lead to useless unit tests)
- MissingTestCategoryCheck (CRITICAL, we only run tests correctly categorized, no category means that the test won't be run)
- NoKnownTestCategoryCheck (CRITICAL, we only run tests correctly categorized, no known category means that the test will never be run)
- ConflictingTestCategoriesCheck (MINOR, conflicting categories means that the test will be run multiple times which is a waste of time)

If some of these checks can be useful to the community I would be glad to write and donate them / ask my company to donate those which are already developed.

Cheers,

Michel