Technical Internals
How the Extension Works Under the Hood

Auto-Mocking: CDI Lifecycle Hooks

The extension uses three CDI lifecycle events to discover unsatisfied injection points and fill them with Mockito mocks.

1. Collecting injection points

<T> void collectInjectionPoints(@Observes ProcessInjectionPoint<?, T> pip) {
    // Records the type and qualifiers of every injection point
}

<T> void collectFromBean(@Observes ProcessBean<T> pb) {
    // Catches inherited generic injection points that some
    // implementations miss in ProcessInjectionPoint
}

The ProcessBean observer is critical for OpenWebBeans compatibility — OWB does not always fire ProcessInjectionPoint for inherited generic fields like BaseDao<E> in an abstract superclass.

2. Registering beans and mocks

During AfterBeanDiscovery, the extension registers (in order):

1. Test class as a @Singleton bean (if addTestClass = true)
2. Inline @Produces @TestBean fields from the active test class — static field values become @Singleton beans
3. Mockito mocks for remaining unsatisfied injection points (skipping types already covered by inline fields, @TestBean alternatives, or third-party extensions)

MockBean properties

@TestBean: Alternative Isolation

When @EnableTestBeans is present, the extension adds three more CDI lifecycle phases before auto-mocking:

Phase -2: Force discovery of scope-less alternatives

During BeforeBeanDiscovery, if a @TestBean-referenced class has @Alternative but no scope annotation, the extension calls addAnnotatedType() to force CDI to discover it in bean-discovery-mode="annotated", then adds @Dependent as the default scope.

Phase -1: Veto conflicting alternatives

During ProcessAnnotatedType, the extension checks each @Alternative bean against the @TestBean set. Bean types are resolved respecting @Typed on both the candidate and the selected alternatives:

• Selected by @TestBean — kept. If it has no scope, @Dependent is added.
• Not selected, bean types clash with a @TestBean-declared alternative — vetoed (regardless of @Priority).
• Not selected, no type clash — left alone. This includes alternatives enabled via @Priority or beans.xml for unrelated types.
• No active test class — alternatives without @Priority are vetoed (inactive anyway, prevents producer conflicts). @Priority alternatives are untouched.

In whitelist mode (limitToTestBeans = true), ALL application beans are vetoed except the whitelisted ones.

Phase 0: Enable selected alternatives

During AfterTypeDiscovery, the extension reads @TestBean annotations from the active test class — recursively walking meta-annotations — and enables each referenced alternative via getAlternatives().add().

JUnit Integration

@EnableTestBeans carries @ExtendWith for the internal JUnit extension. The lifecycle:

Meta-Annotation Resolution

@TestBean declarations are collected recursively from the test class's annotation hierarchy. The algorithm:

1. Read all annotations on the test class
2. For each @TestBean or @TestBeans, collect the bean and beanProducer references
3. For each non-JDK/non-CDI annotation, recurse into its meta-annotations
4. Track visited annotation types to prevent infinite loops
5. Collect into a Set<Class<?>> — duplicates are automatically deduplicated

Third-Party Extension Compatibility

The extension detects types managed by third-party CDI extensions and skips mocking them. Currently recognized:

• Apache DeltaSpike — types whose annotations carry @PartialBeanBinding are skipped. Detection uses annotation name strings to avoid compile-time dependencies.

Package Structure