Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Checkstyle tests should be named after the class they test and extra validations/helpers should be in a special package #5104
Identified at checkstyle/regression-tool#85 (comment) ,
To be able to pull in properties from tests to be used in regression on a module, we need a clear connection between the test and the production code. This is usually defined by naming the test class after the production class and having them in the same package.
Some tests break this rule and we should rename/move them so they are in alignment and there is a clear connection between the 2 classes.
A UT should be created to make sure we don't break this in the future.
Examples of this being broken:
This is a list of tests that should be in a special package (probably
referenced this issue
Sep 12, 2017
Are we ok with test classes with many test methods? I'm sure we have a check against too many methods in a class somewhere.
I didn't look at existing tests when making the list in main description, but it looks like we already have a
@MEZk Feel free to share your input here since you are the project lead.
I'm against such tests. I think that the tests should be split.
The check should be enforsed over test classes, I guess.
Not exactly. It is a kind of test which verifies that all logic which maps DetailAST tree to Xpath-tree works OK. In addition it might be a siginificat source of information for Xpath suppression model users. Maybe it is reasonable to move the test to IT folder.
this is interesting point of discussion.
There is no XpathMapper in our code. XPathEvaluator that is used in internals is class from library(saxon). So we have a case where we have a Test class for non existing "main" class in our project. That is ok and in real life happens a lot.
RootNode (from main area of code) is most close class that is heavy used XpathMapperTest.
IT test code is another mis-usage by us from general meaning of this area.
I don't. Right now I prefer everything in one class. Finding test that hits specific code is easier as you just run class tests and set a breakpoint. It is rare, in checkstyle, that I ever am looking for a specific test over looking for something that hits a specific line in production code.
To me, this seems like a weird place to put it as
I am fine with this or something under