Choose a Spring Boot test by the boundary you need to prove. A plain unit test checks a class in isolation. A web slice checks selected web behavior. A full application context checks broader composition. None automatically proves every external system works.

Imagine a controller that asks an article repository for one record. The repository may be a fake in a web test and a real database adapter in a separate persistence test. Calling both tests “integration” without explaining that difference is not enough.

Which question does each test answer?

  • Plain service test: does a missing article produce the intended application outcome?
  • Web test: does the HTTP route translate that outcome into the expected status and body?
  • Repository test: does the query read the intended record from the chosen database?
  • Full-context test: do the real application registrations start together?
  • Deployment check: can the running service reach its configured dependencies?

These layers overlap by design, but each should have a clear reason. Repeating every combination in a full-context test can make the suite slow without providing a clearer diagnosis.

What does a web slice omit?

A web slice loads selected web-related configuration instead of all application beans. Collaborators outside that scope normally need suitable test replacements or explicit imports. Filters, security and exception advice can still affect the result, so inspect the selected configuration.

Annotation packages and mocking support differ between Boot generations. Use the imports and test dependencies for the version in the project instead of copying a snippet from another release. The test's intended boundary should remain the same even if a package moves.

What would a useful scenario list look like?

Given: repository contains article a1
When: GET /articles/a1
Then: 200 and the expected public title

Given: repository has no matching article
When: GET /articles/missing
Then: 404 without private repository details

Given: repository throws a controlled dependency failure
When: GET /articles/a1
Then: the application's safe server-error contract

This is a test brief, not executable JUnit code. Turn it into the project's existing test style. Use a known fake or mock and assert calls only when those calls are part of the behavior you need to protect.

When do you need a full context?

Use it when the question concerns application wiring, configuration or interactions that a slice intentionally excludes. A context that starts successfully can reveal missing beans or invalid settings. It still might use a mocked client, so describe the replacements.

Starting a context is not the same as making a successful user request. Add the relevant request and response assertion. Conversely, a successful request through a fake does not prove a real connection string or database migration works.

How do external systems remain safe?

Use dedicated disposable resources for database tests. Make their configuration explicit, and prevent a test profile from falling back to production credentials. A test that changes records in a shared environment is not isolated merely because its class name ends in Test.

Keep data unique per test or reset it through a reliable transaction or fixture strategy. Confirm the strategy covers background work and connections outside the test transaction.

How should failures be reported?

Report what ran, which collaborators were real and which were replaced. If a database test could not run, say so separately from passing web tests. Precise boundaries let the reviewer understand both the evidence and the remaining risk.

For interview practice, take one endpoint and design the smallest set of tests that would catch a route error, a validation error and an incorrect query. Explain why one large test would not give equally clear feedback.

References and next practice

docs.spring.io — spring tests

spring-boot question collection · Browse interview topics · Practise a question in Interview Challenge · How to Answer Technical Interview Questions Out Loud