Spring Boot profiles and property precedence: test the selected environment

This lesson uses the downloadable source kit: Java 21, Spring Boot 4.0.8 and its managed Spring Framework 7 dependencies. The version is pinned for repeatable builds.

Make the test environment explicit

The kit’s environment test selects test as the active profile and adds a fixture property source first. It then checks both the active profile and the resolved receipt.mode value. That avoids depending on whichever environment happens to exist on the developer’s machine.

This focused test demonstrates Environment resolution. It does not load a whole application-test.properties file or prove every Boot source-precedence rule. Test those inputs through a real application startup when deployment behavior depends on them.

Do not use a profile as authorization

A prod label is not a security boundary. If a debug endpoint is enabled by a property, a mistaken source override can expose it. The security policy must still reject unauthorized access regardless of which profile assembled the service.

Keep behavior-changing defaults visible and bounded. Use separate credentials for real deployments; the source kit’s local-reader account exists solely for reproducible loopback tests and must not be promoted into an internet-facing user store.

Checked source

StandardEnvironment environment = new StandardEnvironment();
environment.setActiveProfiles("test");
environment.getPropertySources().addFirst(new MapPropertySource("fixture", Map.of("receipt.mode", "dry-run")));
String mode = environment.getRequiredProperty("receipt.mode");

Test the boundary

Run mvn test in the source-kit directory. CoreBoundaryTest.environmentProfileAndPropertyAreExplicit checks the behavior described here. Java excerpts belong to the named source-kit classes; they are not independent source files unless the complete class is shown.

Costs and boundaries

Environment resolution is a configuration operation, not a per-row business rule. Repeatedly querying global properties inside a hot loop hides the chosen contract and complicates tests.

Common Mistakes

• Profiles do not grant authorization.
• Do not depend on an unspecified machine environment.
• Do not deploy the fixture credentials.

Read next

Spring Boot configuration properties: bind values and reject bad startup input, Security filter chain, Java ResourceBundle: locale fallback and missing message keys.

Next boundary checks

Continue with Spring Boot property override: fail startup on the effective value, Java Properties precedence: merge sources deliberately.