Mismatched Test Patterns
carl.log("MockitoExtension + @SpringBootTest = compiles legally, illegally confusing.")
Carl saw a PR with a test.
Carl wanted to learn.
MockitoExtension. @SpringBootTest. TestConfiguration with Mockito.mock beans.
Carl blinked once. Carl blinked twice. Carl spit the lavender tea.
Carl commented.
Carl cried anyway.
basil.log("Unit tests vs integration tests. Know the difference. Use the right tool.")
Unit tests vs integration tests. Different tools. Different purposes.
Unit test:
- Tests a single class in isolation
- Fast (milliseconds)
- Uses mocks for dependencies
MockitoExtensionis appropriate here
Integration test:
- Tests components working together
- Slower (seconds)
- Uses real dependencies (database, Spring context)
@SpringBootTestis appropriate here
The problem: Using MockitoExtension with @SpringBootTest.
@SpringBootTest loads the Spring context. That's integration testing. Use @MockitoBean to mock external dependencies, not MockitoExtension + Mockito.mock().
Better approach:
- Unit test:
MockitoExtension+Mockito.mock()for dependencies (no Spring) - Integration test:
@SpringBootTest+@MockitoBeanfor external services
Spring provides application-test.properties for test-specific configuration. Use it.
Test pyramid: Many unit tests, fewer integration tests, even fewer end-to-end tests.
Mixed patterns create slow tests that don't catch real integration issues. Choose the right tool.
lucy.log("Cognitive dissonance: when patterns don't match what you learned. The self-doubt is normal.")
Carl saw something confusing and wanted to understand. That's healthy curiosity.
Then came cognitive dissonance. Your brain sees a mismatch between what you learned and what you're seeing. That discomfort? That's your brain trying to make sense of conflicting information.
The internal dialogue:
- "I thought unit tests and integration tests were different things."
- "Maybe I'm wrong?"
- "But the documentation says..."
- "Maybe I don't understand Spring testing?"
This self-doubt is normal when patterns don't match expectations. Your brain questions itself before questioning external sources—especially when there's a perceived authority gap.
What helps: Carl commented. That's the right move. Share your understanding, provide resources, stay curious. Maybe you'll learn something new. Maybe they will.
The frustration comes from caring about code quality. That's not a weakness.
You're not wrong for noticing mismatched patterns. Technical confusion is a valid reason to ask questions.