Extend IT tests to able to load few modules from configs

[romani]

discussed in #7542 (comment)

we need to extend AbstractGoogleModuleTestSupport to allow load few modules from config file.

In referenced PR we need to load together for each test:

<module name="RightCurly">
    <property name="id" value="RightCurlyAlone"/>
    <property name="option" value="alone"/>
    <property name="tokens"
     value="CLASS_DEF, METHOD_DEF, CTOR_DEF, LITERAL_FOR, LITERAL_WHILE, STATIC_INIT,
            INSTANCE_INIT, ANNOTATION_DEF, ENUM_DEF"/>
</module>
<module name="SuppressionXpathSingleFilter">
  <!-- suppresion is required till https://github.com/checkstyle/checkstyle/issues/7541 -->
  <property name="id" value="RightCurlyAlone"/>
  <property name="query" value="//RCURLY[parent::SLIST[count(./*)=1]
                                         or parent::OBJBLOCK[count(./*)=2]]"/>
</module>

Attention: id property in Filter is occupied for business logic meaning, so load of specific Filter might be problematic. It might require update in Filters to make id be same as in Check - just identifier.

[rnveach]

we need to extend AbstractGoogleModuleTestSupport to allow load few modules from config file.

Why only a few modules and not the entire config?

[romani]

load of whole config might result in big list of expected violations, I think it will be hard to maintain such tests. I just keep original ideas of it to be module based.

Many years ago I thought that I will easily find open source project(s) that completely follow google style, so it will be our "no violations" test base .... it was naive.

We might create new set of ITs to keep input files and keep violations of whole config, I think it should be separate set ITs.

[rnveach]

load of whole config might result in big list of expected violations

I don't know how hard it will be to make inputs that strict, but it may be good to show that the entire input is compliant except the spots we tell them it will produce violations.

<module name="RightCurly">
<property name="id" value="RightCurlyAlone"/>

<module name="SuppressionXpathSingleFilter">
<property name="id" value="RightCurlyAlone"/>

We should be able to find config by its module name (like we do now), and if it contains an id property, find other modules that have the same id and include them. The above example shows they both use the same id in a property.

[romani]

I always ok to have more tests. Please create new issue on this, if you want it.

[SGanguly1999]

I am on it.

[SGanguly1999]

@romani @rnveach There is a problem I am facing here. All the test functions calls getModuleConfig() which returns a single Configuration object. If we want to extend it to load few more modules we have return a list of Configuration objects. That will require a lot of changes to be made to the it ( Like verify() needs to be overloaded that supports List<Configuration> and all methods linked to it must be overloaded to support the feature). Is there any better way of approaching this one?