`@ContextConfiguration` does not merge duplicate sets of locations or classes within a test class hierarchy about spring-framework HOT 4 CLOSED

All things considered, we don't believe this to be a good change. It's more consistent to do what the users has defined in their configuration, for consistency with what's happening with production code. For hierarchical test cases, like this one, inheritLocations should be used to disable what's coming from the parent if necessary.

from spring-framework.

Code related to this can be found in:

• AbstractTestContextBootstrapper.buildMergedContextConfiguration(Class<?>, List<ContextConfigurationAttributes>, MergedContextConfiguration, CacheAwareContextLoaderDelegate, boolean)
• MergedContextConfiguration.processStrings(String[])

from spring-framework.

Do you think following a similar approach to what's done on activeProfiles would work? You can see this proposal in the branch above

from spring-framework.

Do you think following a similar approach to what's done on activeProfiles would work?

No, I think it's unfortunately a bit more involved than that. Otherwise, we would have enforced uniqueness with a LinkedHashSet for both the locations and classes a long time ago.

Our goal here is actually not to enforce uniqueness within the entire set of locations or classes, because the duplicate presence of a configuration location or class can be intentional (or at least necessary) due to nuances of the overall configuration -- for example, because that's how the production application works. (Note: I'm not saying that any form of duplication is ideal, but I recall that we didn't go for strict uniqueness because of certain use cases in the wild.)

Rather, we want to detect when a certain class in the test class hierarchy declares the same set of locations or classes, in the exact same order, as its superclass. If we detect such accidental duplication, we then want to remove the duplication.

As I hinted at in my previous comment, we would likely need to build that logic into AbstractTestContextBootstrapper.buildMergedContextConfiguration(...).

As a side note, I suppose we would also want to remove any adjacent, duplicate configuration locations or classes.

For example, @ContextConfiguration(locations = {"config1.xml", "config1.xml", "config2.xml"}) and @ContextConfiguration(classes = {"Config1", "Config1", "Config2"}) should probably never load config1.xml and Config1 twice.

from spring-framework.