Spring Boot @SpringBootTest in JUnit - Framework Patterns

Framework Mode - Spring Boot @SpringBootTest

Folder Structure

spring-boot-app/
├── src/
│   ├── main/
│   │   ├── java/
│   │   │   └── com/example/app/
│   │   │       ├── Application.java
│   │   │       ├── controller/
│   │   │       ├── service/
│   │   │       └── repository/
│   │   └── resources/
│   │       └── application.properties
│   └── test/
│       ├── java/
│       │   └── com/example/app/
│       │       ├── controller/
│       │       │   └── ControllerIntegrationTest.java
│       │       ├── service/
│       │       │   └── ServiceUnitTest.java
│       │       └── repository/
│       │           └── RepositoryTest.java
│       └── resources/
│           └── application-test.properties
├── pom.xml
└── README.md

Test Framework Layers

• Test Runner Layer: Uses JUnit 5 to run tests annotated with @SpringBootTest.
• Application Context Layer: Loads Spring Boot application context for integration testing.
• Test Classes: Located under src/test/java, organized by package matching main code.
• Page Objects / Test Utilities: Helper classes for reusable test logic, mocks, or test data builders.
• Configuration Layer: Uses application-test.properties for test-specific settings.

Configuration Patterns

• Profiles: Use Spring profiles like test activated via @ActiveProfiles("test") to load test-specific configs.
• Properties: Separate application-test.properties for database URLs, ports, or mock endpoints.
• Embedded Databases: Use H2 or similar in-memory DB for fast, isolated tests.
• Mock Beans: Use @MockBean to replace real beans with mocks during tests.
• Environment Variables: Override sensitive data like credentials via environment or CI secrets.

Test Reporting and CI/CD Integration

• JUnit Reports: Generate XML reports automatically via Maven Surefire or Gradle test tasks.
• CI/CD Pipelines: Integrate tests in Jenkins, GitHub Actions, or GitLab CI to run on every commit.
• Code Coverage: Use JaCoCo plugin to measure test coverage and fail builds if coverage drops.
• Test Logs: Configure logging to capture detailed test execution info for debugging failures.
• Test Tags: Use JUnit tags to group and selectively run integration tests.

Best Practices

1. Use @SpringBootTest for Integration Tests: It loads full context, so use it only when needed to avoid slow tests.
2. Isolate Tests: Use embedded databases and mock external services to keep tests reliable and repeatable.
3. Organize Tests by Layer: Separate unit tests from integration tests in folder structure and naming.
4. Use Profiles and Properties: Keep test configuration separate from production to avoid side effects.
5. Clean Context Between Tests: Use @DirtiesContext sparingly to reset context if tests modify shared state.

Self Check

Where would you add a new integration test class for a REST controller in this framework structure?

Key Result

Use @SpringBootTest in src/test/java with test profiles and embedded DB for reliable integration tests.

Practice

1. What is the primary purpose of using @SpringBootTest in a test class?

easy

A. To start the full Spring Boot application context for integration testing

B. To mock all dependencies automatically

C. To run only unit tests without loading Spring context

D. To disable Spring Boot features during testing

Solution

1. Step 1: Understand what @SpringBootTest does

   This annotation loads the entire Spring Boot application context, allowing tests to run with all beans and configurations loaded.

2. Step 2: Compare with other testing approaches

   Unlike unit tests that mock dependencies, @SpringBootTest is used for integration tests to check how components work together.

3. Final Answer:

   To start the full Spring Boot application context for integration testing -> Option A

4. Quick Check:

   @SpringBootTest = full app context [OK]

Hint: Full app context means integration test, not mocking [OK]

Common Mistakes:

• Thinking it mocks dependencies automatically
• Using it for simple unit tests
• Assuming it disables Spring Boot features

2. Which of the following is the correct way to annotate a test class to load the Spring Boot context?

easy

A. @SpringBootApplicationTest

B. @SpringBootTestOnly

C. @TestContextLoader

D. @RunWith(SpringRunner.class) @SpringBootTest

Solution

1. Step 1: Identify the standard annotations for Spring Boot tests

   The correct annotations to load Spring Boot context in JUnit 4 are @RunWith(SpringRunner.class) and @SpringBootTest.

2. Step 2: Check the other options

   Options B, C, and D are not valid Spring Boot or JUnit annotations.

3. Final Answer:

   @RunWith(SpringRunner.class) @SpringBootTest -> Option D

4. Quick Check:

   Use @RunWith(SpringRunner.class) with @SpringBootTest [OK]

Hint: Remember: @RunWith + @SpringBootTest for context loading [OK]

Common Mistakes:

• Using non-existent annotations
• Forgetting @RunWith in JUnit 4
• Confusing with @SpringBootApplication

3. Given the following test class, what will be the output when the test runs successfully?

\@SpringBootTest
class MyServiceTest {
    \@Autowired
    private MyService myService;

    \@Test
    void testService() {
        assertNotNull(myService);
        System.out.println("Service is loaded");
    }
}

medium

A. Test passes and prints 'Service is loaded'

B. Test fails because myService is null

C. Compilation error due to missing annotations

D. Test passes but prints nothing

Solution

1. Step 1: Understand what @SpringBootTest does here

   The annotation loads the full Spring context, so myService bean is injected and not null.

2. Step 2: Analyze the test method

   The assertion assertNotNull(myService) passes, and the print statement outputs "Service is loaded".

3. Final Answer:

   Test passes and prints 'Service is loaded' -> Option A

4. Quick Check:

   Bean injected + assertNotNull = pass and print [OK]

Hint: If context loads, @Autowired bean is not null [OK]

Common Mistakes:

• Assuming myService is null without context
• Forgetting that @SpringBootTest loads beans
• Confusing compilation errors with runtime behavior

4. You have a test annotated with @SpringBootTest but it fails with a NoSuchBeanDefinitionException. What is the most likely cause?

medium

A. The test method is private

B. The test class is missing @Test annotation

C. The bean is not defined or scanned in the application context

D. The Spring Boot version is outdated

Solution

1. Step 1: Understand the exception meaning

   NoSuchBeanDefinitionException means Spring could not find a bean of the required type in the context.

2. Step 2: Identify common reasons for missing beans

   This usually happens if the bean is not defined, not annotated with @Component/@Service, or not in a scanned package.

3. Final Answer:

   The bean is not defined or scanned in the application context -> Option C

4. Quick Check:

   Missing bean definition = NoSuchBeanDefinitionException [OK]

Hint: Missing bean means not defined or scanned [OK]

Common Mistakes:

• Blaming test method visibility
• Assuming missing @Test causes bean errors
• Thinking Spring Boot version causes missing bean

5. You want to speed up your test suite by loading only a part of the Spring Boot context. Which approach can you use with @SpringBootTest to limit the loaded beans?

hard

A. Remove @SpringBootTest and use plain JUnit tests

B. Use @SpringBootTest(classes = YourConfig.class) to load only specific configuration

C. Add @MockBean to all beans manually

D. Use @SpringBootTest with @Transactional only

Solution

1. Step 1: Understand how to limit context loading

   By specifying classes attribute in @SpringBootTest, you can load only selected configuration classes, reducing context size.

2. Step 2: Evaluate other options

   Removing @SpringBootTest disables context loading, @MockBean mocks beans but does not limit context size, and @Transactional controls transactions, not context loading.

3. Final Answer:

   Use @SpringBootTest(classes = YourConfig.class) to load only specific configuration -> Option B

4. Quick Check:

   Limit context by specifying classes in @SpringBootTest [OK]

Hint: Specify classes attribute to limit context [OK]

Common Mistakes:

• Thinking @MockBean reduces context size
• Removing @SpringBootTest disables context, not limits
• Confusing @Transactional with context loading