New Check: AnnotatedMethodNameCheck to check method names of annotated (test) methods about checkstyle HOT 9 OPEN

conceptually, after shallow review, I am good with proposal.

can this be a solution https://checkstyle.org/checks/coding/matchxpath.html#MatchXpath ?

you can find bunch of example in our issue tracker and discussions, like #12975 (comment)

from checkstyle.

The Google Conventions also suggest a specific pattern for test methods.
By implementing the proposed Check, those conventions could be enforced via Checkstyle.

Could you please explain a bit on where a specific pattern is mentioned for annotated test methods?
From what I know, google style guide only asks for the method names to follow lowerCamelCase.. am I wrong here?

does not match pattern "^test.*$"

I agree we may use this by convention (even in our code) but enforcing this on all users is a major debate.

Some coding conventions, like the one used for my uni project

Could you please share examples of such style schemes?

from checkstyle.

@MANISH-K-07

Could you please explain a bit on where a specific pattern is mentioned for annotated test methods? From what I know, google style guide only asks for the method names to follow lowerCamelCase.. am I wrong here?

The Google Style Guide doesn't specify a pattern for test methods:

There is no One Correct Way to name test methods.

However it suggests that a pattern may be used:

One typical pattern is <methodUnderTest>_<state>, for example pop_emptyStack

does not match pattern "^test.*$"

I agree we may use this by convention (even in our code) but enforcing this on all users is a major debate.

Both the pattern and annotations are properties which can be adjusted to the user's needs.
I think those might be good default values tho. But we can totally change those. It's just the example that prompted me to make a Check like this.

Some coding conventions, like the one used for my uni project

Could you please share examples of such style schemes?

Test methods schould be named "test" + method name.

There are some special methods with specific annotations which should always be named the same:

from checkstyle.

Test methods schould be named "test" + method name.
There are some special methods with specific annotations which should always be named the same:

Some coding conventions, like the one used for my uni project, set rules for the naming of test methods,

I have understood your vision previously. Please provide sources/links to such code styles that support your statement above

However it suggests that a pattern may be used:

A bit of clarity here.. the new check wants to focus only on targeted methods ? (I don't think this is what google style implied)
Because we already have a property that allows this CS check to be customized by user with regex for method name identifier?

from checkstyle.

@MANISH-K-07

I want only certain annotated methods to be checked. The current MethodName Check doesn't allow that functionality. It will always check methods whether annotated or not.

Actually, the best thing to do would be to extend the current MethodName Check to be able to filter only certain annotated methods. Then a new Check won't be necessary. I suppose this issue could be changed to an extension for MethodName then?

Please provide sources/links to such code styles that support your statement above

I have provided a link to the Google conventions, which mentions a pattern. I cannot link to internal uni project conventions tho. But I am sure there are many conventions for test method out there. Regardless, I think this is a useful feature, allowing users more control.

from checkstyle.

It will always check methods whether annotated or not.

This doesn't need a new check. We make use of certain properties to restrict/limit/enhance/extend existing check accordingly.

I have provided a link to the Google conventions, which mentions a pattern
But I am sure there are many conventions for test method out there

This is where we are stumbling around.. From what I know of the project, we don't introduce new functionalities based on assumptions or very few uni conventions. For a new functionality to be implemented, it needs to be backed up by a reliable code style scheme. I hope you understand what I mean, we can't force users to follow something that is limited to few unis or random conventions.

Regardless, I think this is a useful feature, allowing users more control.

This, however is not in my power to decide, let's wait for the maintainers' opinion.
If they decide it beneficial for the project, then a new property will suffice, new check is not required :)

from checkstyle.

can this be a solution https://checkstyle.org/checks/coding/matchxpath.html#MatchXpath ?

Theoretically yes, we should be able to evaluate an xpath query that matches targeted node

from checkstyle.

@romani

can this be a solution https://checkstyle.org/checks/coding/matchxpath.html#MatchXpath ?

I believe so, yes. I have not looked much into Xpaths, but they seem very powerful.

In that case, I think it might be useful to mention them in the documentation more explicitly. I had the impression I would have to change or add a new Check. This would keep users from implementing checks that Xpath could accomplish easily.

conceptually, after shallow review, I am good with proposal.

Does that mean the functionality I described should be added to Checkstlye? Or it should not, since Xpath could do the same?

from checkstyle.

Try to make it by xpath first, such attempt usually shows and items that xpath is not able to do. So reason for new Check will be more explicit.

from checkstyle.