DEV Community: Dominik Kovács

Keeping dev-only beans out of the jar

Dominik Kovács — Fri, 21 Aug 2026 12:30:00 +0000

The setup code nobody wants in production

Some infrastructure has to be created before the application can use it, and who creates it depends
on where the application runs. DynamoDB is a clear case. In production the tables are provisioned by
Terraform or CDK before anything deploys. Locally and in tests, nothing has provisioned them, so the
application has to do it itself or immediately fail on a missing table.

There is nothing built in to do it. Relational databases get schema.sql and Flyway, but the AWS
SDK has no equivalent, so the table creation ends up as an ApplicationRunner with a profile
limiting where it runs.

CatalogConfiguration.java

@Bean
@Profile("dev | test")
ApplicationRunner createProductTable(DynamoDbEnhancedClient enhancedClient) {
    return args -> enhancedClient.table("product", TableSchema.fromBean(Product.class))
            .createTable();
}

TableSchema.fromBean reads the key and attributes off the annotated Product class, so the table
is created from the same mapping the application already uses to read and write it.

This works, and it ships. The runner is in the jar and createTable is in the jar, so the guarantee
is only as good as the active profiles staying right on every environment forever. A shared base
configuration that carries dev, a copied Helm chart, a machine where someone exported
SPRING_PROFILES_ACTIVE and forgot, and the code is live against a real table. Nothing warns you,
because as far as Spring is concerned the bean did what it was told.

Where the code lives, not what the profile says

src/test/java compiles to target/test-classes, and the Spring Boot plugin does not package that
directory. Move the table creation there and it is not in the artifact at all.

Building the same project with that bean in src/test/java gives a jar containing only the
application code.

BOOT-INF/classes/com/example/catalog/CatalogApplication.class
BOOT-INF/classes/com/example/catalog/Product.class
BOOT-INF/classes/com/example/catalog/ProductController.class

No table creation anywhere in it. Test-scoped dependencies are absent from the runtime classpath
too, so a fake implementation that needs a container library does not drag it into production
either.

That is a different kind of guarantee from the profile version. A profile is evaluated at runtime,
which means the code is present and something decided not to call it. A classpath is decided when
the artifact is built. Production cannot create the table because the bytecode is not there, and
no configuration mistake can put it back.

The shape that falls out of this puts everything the application ships on one side and everything
that only runs on a developer machine on the other.

src/main/java/com/example/catalog/
    CatalogApplication.java
    Product.java
    ProductController.java
src/main/resources/
    application.yaml
src/test/java/com/example/catalog/
    TestCatalogApplication.java
    LocalDynamoDbConfiguration.java
    ProductRepositoryTest.java
src/test/resources/
    application.yaml
    application-dev.yaml

1. TestCatalogApplication is the local entry point, and the only main method that knows
about any of this.

2. LocalDynamoDbConfiguration holds the container and the table setup.

3. ProductRepositoryTest is an ordinary test that imports that same configuration.

4. This application.yaml needs care. Both files answer to classpath:/application.yaml and
test classes come first, so it does not merge with the shipped file, it hides it. Anything the
application needs in every environment has to be repeated here or moved into a profile file
alongside it.

5. application-dev.yaml carries the ports and URLs that only make sense on a laptop.

Nothing under src/test is in the jar, which means the division is not a naming convention that has
to be policed. The build enforces it.

Starting the application from your tests

Moving that bean raises the obvious problem. spring-boot:run uses the main classpath, so the bean
you just moved is invisible when you start the application locally, which is exactly when you wanted
it.

Boot has a second goal for this. spring-boot:test-run starts the application with test classes and
test dependencies included, and it prefers a main class found in the test classes directory. So the
launcher lives in src/test/java next to everything else that only dev needs.

TestCatalogApplication.java

public class TestCatalogApplication {

    public static void main(String[] args) {
        SpringApplication.from(CatalogApplication::main)
                .with(LocalDynamoDbConfiguration.class)
                .run(args);
    }
}

SpringApplication.from runs the real application and adds beans to it. The production entry point
is untouched, and there is no second @SpringBootApplication to keep in sync.

What it adds is the container, and the table creation that depends on it.

LocalDynamoDbConfiguration.java

@TestConfiguration(proxyBeanMethods = false)
class LocalDynamoDbConfiguration {

    @Bean
    @ServiceConnection
    LocalStackContainer localStack() {
        return new LocalStackContainer(DockerImageName.parse("localstack/localstack:4"));
    }

    @Bean
    ApplicationRunner createProductTable(DynamoDbEnhancedClient enhancedClient) {
        return args -> enhancedClient.table("product", TableSchema.fromBean(Product.class))
                .createTable();
    }
}

1. @TestConfiguration applies only where something imports it, which is the launcher above.
Nothing here is picked up by starting the application normally.

2. @ServiceConnection is what removes the configuration. Spring Cloud AWS contributes a
factory for LocalStack, so the endpoint and credentials of the started container become the AWS
client configuration with nothing written in application.yaml.

Importing by name is also what lets a test reuse the whole setup. An integration test that wants the
same container and the same table asks for it.

ProductRepositoryTest.java

@SpringBootTest
@Import(LocalDynamoDbConfiguration.class)
class ProductRepositoryTest {

}

The local run and the tests that opt in now share one definition of what the environment looks like,
and tests that do not import it are unaffected. That reuse is the practical argument for putting the
configuration in src/test/java rather than somewhere only the application can reach.

Now one command boots the whole thing.

mvn spring-boot:test-run -Dspring-boot.run.profiles=dev

LocalStack starts, @ServiceConnection points the DynamoDB client at it, the runner creates the
table, and the application comes up talking to a real DynamoDB implementation. Gradle has the same
thing as bootTestRun.

spring-boot:test-run activates no profile on its own, so dev has to be named. On the command
line it applies to local runs only, and the test suite keeps whatever profiles its tests ask for.

The dev profile file belongs there too

Beans are not the only thing that leaks. Think about what a dev profile file actually holds. A port
chosen so two services can run side by side, third-party URLs pointing at a sandbox or a stub on
localhost, a log level nobody wants in production, credentials that are fake precisely because the
services they unlock are fake. None of it is meaningful outside the machine it was written for, and
src/main/resources/application-dev.yaml ships every line of it.

src/test/resources is left out of the jar exactly like src/test/java, so that is where the file
belongs.

src/test/resources/application-dev.yaml

server:
  port: 9090
spring:
  http:
    serviceclient:
      pricing:
        base-url: http://localhost:9091
logging:
  level:
    com.example.catalog: DEBUG

Outbound HTTP is the part worth dwelling on, because tests and local development want different
things from the same client. A test stubs the response, since it is asserting on the caller rather
than the callee. Running locally you usually want the request to actually go somewhere, either a
service started on another port or a stub server standing in for it.

The key under serviceclient is the group name the client was declared with.

@ImportHttpServices(group = "pricing", types = PricingClient.class)

Starting with dev active reads the file, so the client issues real requests to port 9091. The test
suite does not activate it, so the same client stays stubbed there. Two behaviours from one
declaration, and none of those local values are in the artifact.

Production configuration stays where it always was, in src/main/resources/application.yaml,
pointing at the real service. There is no dev block sitting next to it for somebody to activate by
accident.

What profiles are still good for

None of this makes profiles the wrong tool. They are the wrong tool for one specific job, which
is keeping code out of production, because they answer at runtime a question the build already
knows the answer to. Choosing between local and test behaviour, as dev does above, is exactly
what they are for, and it works the same inside src/test.

The distinction worth keeping is between choosing behaviour and excluding code. Profiles choose.
Only the classpath excludes.

When this is not enough

A deployed environment runs the real jar. Staging, a shared dev cluster, a preview deployment, all
of them get the artifact with target/test-classes left out, so a bean in src/test/java cannot
help them. If a deployed environment genuinely needs to create its own tables, this technique does
not reach it, and the honest options are a separate module that only that environment depends on,
or a profile with the leak risk accepted and guarded.

The technique fits the case where the code is for the machine doing the building. Local runs and the
test suite both use the test classpath, which is why one bean can serve both, and why production
never has to be trusted to skip it.

Vertical slices in Spring Boot, and how to test them

Dominik Kovács — Fri, 21 Aug 2026 09:07:00 +0000

Where did the feature go

Most Spring Boot projects start with the structure everyone recognises.

controller/
service/
repository/
dto/
entity/

It reads well when there are four classes in it. The problem arrives later, when adding one feature
means editing a controller here, a method on a service there, two DTOs in a third package, and a
repository query in a fourth. Nothing about that change is complicated. It is just spread out.

The alternative is to make the feature the unit of organisation rather than the technical role.

order/
    OrderController.java
    OrderService.java
    OrderRepository.java
    OrderRequest.java
    OrderResponse.java
customer/
payment/

Everything an order needs lives in order. That is a vertical slice, one business capability cut
through every technical layer it happens to use.

The feature owns its whole stack

The interesting consequence is not the folder. It is that the classes inside stop being public.

In a layered layout a service in service has to be visible to a controller in controller, so
every one of those types is public, which in Java means available to the entire codebase. You wanted
"the controller may call the service" and the language made you write "anyone may call the service".

Put them in the same package and the calls stop crossing a boundary at all.

OrderService.java

@Service
class OrderService {

    private final OrderRepository orders;
    private final PaymentGateway payments;

    OrderService(OrderRepository orders, PaymentGateway payments) {
        this.orders = orders;
        this.payments = payments;
    }

    @Transactional
    OrderResponse place(OrderRequest request) {
        var order = Order.from(request);
        payments.authorise(request.customerId());
        return OrderResponse.of(orders.save(order));
    }
}

OrderController.java

@RestController
class OrderController {

    private final OrderService service;

    OrderController(OrderService service) {
        this.service = service;
    }

    @PostMapping("/orders")
    OrderResponse place(@RequestBody OrderRequest request) {
        return service.place(request);
    }
}

No public on either. customer cannot import OrderService, and not as a matter of policy. The
compiler rejects it, on every machine, including the one belonging to whoever joins next year and
never read the team conventions.

That is the part a layered structure cannot give you. It has to expose every layer to the next, so
"no feature depends on another feature" stays a convention you check in review rather than something
the build enforces.

PaymentGateway is the one type in there that comes from outside the feature, which is a problem of
its own and gets a section further down.

What still has to be shared

Two things usually escape the feature package, and it is worth being deliberate about both.

The first is the domain model, when several features genuinely write to the same rows. Those
invariants belong to the domain, not to whichever feature touched them last, so they get a home of
their own.

order/
    domain/
        Order.java
        OrderItem.java
        OrderRepository.java
    OrderController.java
    OrderService.java

Java package visibility does not nest, which surprises people. As far as the compiler is concerned
order.domain is a different package from order, with no privileged access to it, and there is no
modifier meaning "visible to my subpackages". Move Order down a level and it has to become
public. That is a real cost, and a reason not to introduce subpackages until something forces you.

The second is genuine infrastructure, meaning security configuration, error handling, or an
interceptor that adds a request identifier to the logging context. None of that is a feature, and
pretending otherwise helps nobody.

web/
    SecurityConfiguration.java
    ApiExceptionHandler.java

What should not escape is a helper extracted because two features looked similar once. A shared
OrderUtils that both order and payment depend on has coupled them together in a way the
package structure now hides. Duplication between features is usually cheaper than a shared
abstraction serving two masters, and the third occurrence tells you far more about the right shape
than the second one does.

When one feature needs another

Placing an order has to authorise a payment. Payments are their own feature, so what does order
call?

The tempting answer is to inject payment's service directly. That works, and it quietly undoes the
thing you just built. payment now has to make that class public, order compiles against
payment's internals, and you have a dependency the package structure claims does not exist.

Two options keep the boundary intact.

The first is to publish a deliberately small interface from the feature being called, and treat that
as its contract rather than an accident of its implementation.

payment/
    PaymentGateway.java        <- public, the contract
    PaymentService.java        <- package-private, the implementation
    StripeClient.java          <- package-private

order depends on PaymentGateway and nothing else. The one public type is the price of the
dependency, and because it is the only one, it is a decision somebody had to make on purpose rather
than a side effect of layering.

The second is to invert it. Publish an event from order and let payment subscribe.

OrderService.java

@Transactional
OrderResponse place(OrderRequest request) {
    var order = orders.save(Order.from(request));
    events.publishEvent(new OrderPlaced(order.id(), order.total()));
    return OrderResponse.of(order);
}

Now order knows nothing about payments at all, and payment decides for itself what to do when an
order appears. That is a stronger boundary, and it costs you the ability to reason about the whole
operation in one place. Use it when the reaction is genuinely optional or asynchronous, and the
interface when the caller needs the result before it can continue.

Either way, a feature calling another feature should be visible, deliberate and narrow. What you are
avoiding is not the dependency itself, it is the dependency nobody chose.

Tests that mirror the structure

Here is the part that changes day to day. Because the feature is a package, its tests are the same
package, and a failing test names the broken capability rather than a layer.

src/test/java/com/example/shop/
    order/
        OrderSliceTest.java
    customer/
        CustomerSliceTest.java

Tests living in the same package is also what makes package-private classes testable without
loosening anything. Maven and Gradle both put src/test/java on the same package namespace, so the
test sees the class while the rest of the application still cannot.

The test that follows from this packaging is one per feature. Name the classes of the feature and
run the whole thing, from the HTTP request to the rows in the database.

OrderSliceTest.java

@Testcontainers
@SpringBootTest(classes = {OrderController.class, OrderService.class})
@EntityScan(basePackageClasses = Order.class)
@EnableJpaRepositories(basePackageClasses = OrderRepository.class)
@ImportAutoConfiguration({
        DataSourceAutoConfiguration.class,
        HibernateJpaAutoConfiguration.class,
        TransactionAutoConfiguration.class,
        WebMvcAutoConfiguration.class})
@AutoConfigureMockMvc
@Transactional
class OrderSliceTest {

    @Container
    @ServiceConnection
    static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:17");

    @Autowired
    MockMvcTester mvc;

    @Autowired
    OrderRepository orders;

    @MockitoBean
    PaymentGateway payments;

    @Test
    void placesOrder() {
        assertThat(mvc.post().uri("/orders")
                .contentType(APPLICATION_JSON)
                .content(orderWith(2)))
                .hasStatus(HttpStatus.OK);

        assertThat(orders.findByCustomerId(42L)).hasSize(1);
    }

    @Test
    void rejectsOrderWithMoreThanTenItems() {
        assertThat(mvc.post().uri("/orders")
                .contentType(APPLICATION_JSON)
                .content(orderWith(11)))
                .hasStatus(HttpStatus.BAD_REQUEST);

        assertThat(orders.findByCustomerId(42L)).isEmpty();
        verifyNoInteractions(payments);
    }
}

1. Naming the classes is what keeps this a slice. The context holds the controller and the
service of one feature, and nothing else in the application is loaded.

2. Naming them also turns off component scanning, so the entity has to be pointed at by hand.
Leave this out and Hibernate starts with no mapped types.

3. Same for the repository, which is an interface that something has to generate an
implementation for.

The four autoconfigurations below are the rest of what this slice needs. Listing them is the price
of not booting the application, and the list ends up being a fair description of the feature's real
dependencies.

4. The one stub in the test, because PaymentGateway is the one dependency that leaves the
feature. Everything else in the slice runs for real.

One test class, and the request travels the entire slice. JSON deserialisation, validation, the
controller, the service, the transaction, Hibernate, and a real Postgres. The assertion afterwards
reads the rows back, so nothing along that path is assumed.

Stub at the edges of the slice, never inside it. A stubbed repository would have left the SQL and
the mapping untested, which is most of what actually goes wrong, and running the real thing is what
lets the second test assert that a rejected order leaves the database untouched. That is a claim
about the feature end to end rather than about any class inside it.

Nothing from customer or payment is in the context, so a change in either cannot break this
test. That containment is also why one test per feature stays practical as the application grows.
The context is a function of the slice, not of the codebase, so the tenth feature does not slow down
the first feature's test.

When layers are fine

If every feature in the application has the same shape, layers cost nothing and give each kind of
file one obvious home. A CRUD service over a dozen tables does not need any of this.

Slices start paying when features stop resembling each other, and when parts of the system change
at different rates. The signal is practical rather than architectural. If implementing one feature
means opening ten packages, the structure is organised around the framework. If everything you need
to understand it sits under order/, it is organised around the work.

Conditional decorator beans in Spring

Dominik Kovács — Thu, 20 Aug 2026 23:19:00 +0000

The flag nobody should have to remember

Address verification APIs bill per lookup. So do identity screening, document extraction, and most
other useful third-party services. They also tend to offer a sandbox mode that returns plausible
data for free, which is what you want everywhere except production.

The obvious way to wire that up is a check where the call happens:

don't do this

if (properties.isSimulate()) {
    return client.verify(request.withSandbox(true));
}
return client.verify(request);

It works. It also means the flag is now part of your business logic, and every future call site is
one more place to forget it. The place that forgets is the one that bills you from a CI run.

A bean that wraps its own interface

Put the flag in a bean instead:

SandboxAddressClient.java

@Primary
@Component
@ConditionalOnBooleanProperty("address.simulate")
class SandboxAddressClient implements AddressClient {

    private final AddressClient delegate;

    SandboxAddressClient(AddressClient delegate) {
        this.delegate = delegate;
    }

    @Override
    public AddressResult verify(AddressRequest request) {
        return delegate.verify(request.withSandbox(true));
    }
}

1. @Primary is what keeps this invisible. Callers still ask for AddressClient and now get
the wrapper, so you don't touch a single call site and new callers inherit the behaviour without
knowing it exists.

2. @ConditionalOnBooleanProperty does more than switch behaviour off. When the property is
false the bean is never created, so there is nothing in the context to misconfigure and no branch
to trace at runtime. Either the decorator is there or it isn't.

3. The undecorated client, injected into its own decorator, which is the part that looks
impossible.

Why this is not a circular dependency

A class that implements AddressClient and injects AddressClient looks like it should blow up on
startup. It would, if it were the only implementation.

What saves it is that @Primary applies to other beans asking for the type, not to the bean's own
constructor. Spring needs an AddressClient to build SandboxAddressClient, leaves out the bean
it's currently constructing, and finds one remaining candidate. That's the real client. Without that
exclusion you'd be adding qualifiers and the two beans would need to know about each other.

The other thing worth noticing is that the decorator doesn't fake anything. The request still
serializes, authenticates, and comes back through the same error handling as production. Only the
sandbox flag changes. Swap in a mock and you skip all of it, which is usually where the bugs live.

What else this fits

Any metered API with a sandbox works the same way. So does disarming something with a real-world
effect, like notifications or webhook deliveries, where you want staging to go through the motions
without anyone receiving anything.

It also works for behaviour you only want in some deployments. Cache a read-heavy client in
production but not locally, so you see fresh data while developing. Mask personal data in
environments where a lot of people have access, and leave it alone where the access is legitimate.

The pattern holds as long as the decision comes from where the application runs. If it depends on
anything in the request, this is the wrong tool.

When the indirection stops paying

As soon as the wrapper starts deciding things per request, which lookups get sandboxed or which
users get masked, put the flag in the request and be explicit about it. Request-dependent logic
hidden behind @Primary is the kind of cleverness people curse at later.

There is a genuine cost even in the simple case. Someone debugging a call site sees an interface and
gets no hint that a decorator is in the way. That's a fine trade when the wrapper does one
environment-shaped thing you can explain in a sentence. It stops being fine once the decorator has
business rules of its own, because nobody reading the caller has any reason to look for it.

You can stack these, but only one bean can be @Primary. Past that you're ordering a chain by hand,
and at that point a configuration class that builds the stack in plain sight beats spreading it
across annotations.