Test method name standard

[willr3]

Should we have a standard for Test method names?

1. I've noticed several test<MethodName><TestCondition>
2. I personally prefer <methodName>_<test_condition>
3. and there is also <methodName><TestCondition>
4. and for completeness <methodName>_<TestCondition>
5. <methodName>_<testCondition>

If we decide on a standard I am personally in favor of option 2 because it copies the method name as it appears in the code (camelCase) and I find it easier to read the test condition in snake_case instead of continuing the CameCase but that only is one dev's opinion.

Do we have preferences on this? Do we want to adopt a standard across tests?

[willr3]

I looked over a bunch more test names and I think my preference is to start with the method under test (matching case) then a separator _ then the test condition in whatever case we all agree upon.

[stalep]

The standard we've had is option 1. There might be some instances of option 3, but those are rare (I think).
I do prefer camel case and I think it is something we should continue with. I do not see any reason to have one standard for test method names and another for source method names.

[lampajr]

Thanks @willr3 for raising this up 🙏

I think that option 1 and option 3 matches the Java naming convention best practices so I would tend to follow that approach, i.e., CamelCase for every method/variable.

On the other hand I would not force to have a fixed pattern, [test]<MethodName><TestDescription> as there might be cases where the method itself is already too long. In that case I think the description would be enough (i.e., something like [test]<TestDescription>).

[willr3]

I do not see any reason to have one standard for test method names and another for source method names.

We all agree that camelCase is the Java standard for source methods. I think source methods and test methods address different goals and therefore the method names serve different purposes.

Source methods encapsulate a logical process for reuse. That goal means the naming is short and descriptive of what it does. We have all seen jokes of long method names making it cumbersome to read code and there is even a code smell where long names tend to indicate too much logic is contained in a single method.

Test methods ensure consistent behavior for a known input condition. I don't believe we have any re-use between the test methods so I do not believe the naming convention should adhere to the same brevity goals as source methods. I would argue the goal of naming a test method is to describe what is being tested and the test condition.

For unit tests that usually means testing a target source method and describing the input conditions. the standard camelCase works well when the input condition is simple (toInstantNulls) but I find longer test conditions pose a challenge to continuous camelCase. For example, in the composable labels work I would have a test calculateLabelValuesLabelValueExtractorJsonpathOnIterated which option 1 would rename to testCalculateLabelValuesLabelValueExtractorJsonpathOnIterated but in my source the method name is calculateLabelValues_LabelValueExtractor_jsonpath_on_iterated. The mixed case method name makes it easier to see the method name is calculateLabelValues and the test condition is testing the LabelValueExtractor class with jsonpath on an iterated value.

I think the test prefix for option 1 is redundant and is a carryover from before annotations when test frameworks had to reflect on method names to find the tests. We have a @Test annotation and the class names traditionally end with Test or IT. I think we are able to identify tests without having each method name start with a common prefix.

If we decide to continue with option 1 or 3 then I worry test method names will shorten to be more readable and less descriptive of what is being tested. Perhaps option 5 so we preserve the camelCase preferences but we clearly separate the target method from the test description?

[stalep]

For unit tests that usually means testing a target source method and describing the input conditions. the standard camelCase works well when the input condition is simple (toInstantNulls) but I find longer test conditions pose a challenge to continuous camelCase. For example, in the composable labels work I would have a test calculateLabelValuesLabelValueExtractorJsonpathOnIterated which option 1 would rename to testCalculateLabelValuesLabelValueExtractorJsonpathOnIterated but in my source the method name is calculateLabelValues_LabelValueExtractor_jsonpath_on_iterated. The mixed case method name makes it easier to see the method name is calculateLabelValues and the test condition is testing the LabelValueExtractor class with jsonpath on an iterated value.

I think the test prefix for option 1 is redundant and is a carryover from before annotations when test frameworks had to reflect on method names to find the tests. We have a @Test annotation and the class names traditionally end with Test or IT. I think we are able to identify tests without having each method name start with a common prefix.

Yes, I agree that option 1 is redundant and only because of junit restrictions back in the day.
Personally, I have no trouble reading a longer word that's typed with camelCase vs snakeCase. I also fear that starting using snakeCase in tests would propagate into the source eventually.

Regarding option 5, I think it put too much restriction to what we should/shouldn't do. We have several methods that does a lot of things to mimic some sort of behavior. Some tests would fit the description of option 5, many would not.

My vote would go to option 3.

[willr3]

I've updatd my PR to use option 3 for the time being but I do not think readability is equivalent between camelCase and snake_case when the number of words increases.

Personally, I have no trouble reading a longer word that's typed with camelCase vs snakeCase

we use spaces when communicating conditions outside of a test method name and I see _ as a closer approximate to our normal way to communicate conditions than the camelCase approach of removing punctuation and using capitalization.

I also fear that starting using snakeCase in tests would propagate into the source eventually.

Java is already a mixture of UpperCamelCase, camelCase, and SCREAMING_SNAKE_CASE (aka MACRO_CASE) depending on the context and we do a rather good job of using the correct case in the correct context. I agree that snake_case would not be ideal in source method names because of the goals I mentioned earlier. We do already use snake_case in our source when specifying sql tables and columns, but that has not propagated into our method names.

[whitingjr]

Personally I find 1. useful for navigating unit/integration test classes to lookup a method. Starting a search with the text test to filter the results. Also navigating in Recent Locations. Moving away from 1. removes an easy classification of source vs test code.

[willr3]

That is an interesting workflow. are you using text based search for the test substring to find method declarations? What tool / context are you using (intellij, vscode, vi..)? In Intellij I open the target test class and open the list of methods with ctrl+f12

[whitingjr]

Yes IntelliJ, File Structure to list the methods and then test to filter the list.