Revisit `CachingByArgumentsLengthPartialFormatter` implementation

[sbrannen]

Overview

Now that we cache {arguments} patterns globally (see #4804), we should revisit the need for and/or implementation of CachingByArgumentsLengthPartialFormatter in ParameterizedInvocationNameFormatter.

At a glance, it appears that CachingByArgumentsLengthPartialFormatter is more like a memoizing factory rather than a cache, somewhat analogous to NamespacedHierarchicalStore.MemoizingSupplier.

In other words, it appears that the size of the cache in CachingByArgumentsLengthPartialFormatter is only ever 0 or 1. If that's the case, we probably do not need to store the result in a ConcurrentHashMap.

Related Work

• Commit bff769d
• Cache generated {arguments} patterns for parameterized tests #4804

[sbrannen]

@marcphilipp, I assigned this to you and myself, so that we can discuss the topic once you're back "in the office".

[marcphilipp]

In other words, it appears that the size of the cache in CachingByArgumentsLengthPartialFormatter is only ever 0 or 1. If that's the case, we probably do not need to store the result in a ConcurrentHashMap.

If the number of provided arguments varies, the cache size is larger than 1. For example, for this parameterized test method, it will be 3:

@ParameterizedTest
@CsvSource({"a", "a,b", "a,b,c"})
void test(ArgumentsAccessor argumentsAccessor) {}

Therefore, I think we should keep CachingByArgumentsLengthPartialFormatter in place as-is.