Improve testability of new Profiles support [SPR-16962]

[spring-projects-issues]

Andy Wilkinson opened SPR-16962 and commented

The introduction of the Profiles type in #17063 has made verifying that a call to Environment.acceptsProfiles has been made more difficult. When String was used, verification with Mockito was easy:

verify(this.environment).acceptsProfiles("dev");

With the new Profiles type this will fail as ParsedProfiles does not override equals:

verify(this.environment).acceptsProfiles(Profiles.of("dev"));

The best that I have come up with is to capture the argument that's passed into acceptsProfiles, abuse matches to capture the names of the profiles, and assert that they are as expected:

ArgumentCaptor<Profiles> profiles = ArgumentCaptor.forClass(Profiles.class);
verify(this.environment).acceptsProfiles(profiles.capture());
List<String> profileNames = new ArrayList<String>();
profiles.getValue().matches((profile) -> {
	profileNames.add(profile);
	return false;
});
assertThat(profileNames).containsExactly("dev");

---

Affects: 5.1 RC1

Issue Links:

• Support AND operator in @Profile annotation [SPR-12458] #17063 Support AND operator in @Profile annotation

[spring-projects-issues]

Stéphane Nicoll commented

 With the new Profiles type this will fail as ParsedProfiles does not override equals

Good catch. Implementing equals there may not be the easiest thing to do if we want to make this right. The input arguments can be provided in any order and that makes still two Profiles equal. Same thing within an expression to some extent.

I understand the problem but I am not keen to implement a basic equals for the purpose of restoring a simple "string" checks. Do you have any suggestion?

[spring-projects-issues]

Andy Wilkinson commented

I wasn't necessarily suggesting that implementing equals was the answer. It was just the first thing that I tried after upgrading the code to remove the use of deprecated methods. That said, from a usage perspective, implementing equals feels to me like the right thing to do. I suspect it could prove useful outside of tests as well.

[sbrannen]

In the interim this got reported separately in #25340 and fixed.

In light of that, I am closing this as a:

• duplicate of Profiles should be comparable when created via Profiles.of() #25340

@wilkinsona, feel free to provide additional feedback if you think this issue should be reopened.