#20582 and #20711 fixed a similar bug. The problem still exists if calling ctx.getBean(name, type) for a null-bean which in older Spring versions (pre 5) returned null and now throws a org.springframework.beans.factory.BeanNotOfRequiredTypeException.
I'm afraid this is by design as of Spring Framework 5: getBean never returns null now (in order to allow Java and in particular Kotlin callers to rely on a non-null result), and the NullBean instance indeed cannot be coerced to the specified type there. Note that dependency resolution at injection points may still result in null, just not getBean calls.
For a testing scenario like yours, you could simply call the plain getBean variant without an expected type and check its result for .equals(null) (matching against the NullBean instance at runtime).
Cleaner nullability at the API level is a general Spring Framework 5 theme. We're aware that this may cause some regressions against specific API expectations: However, we need this clearer distinction of an uninitialized value (null) versus a fully initialized bean where a factory method happened to return null (where we're exposing a managed NullBean instance for this rather rare case now).
Injection points (in particular annotation-based ones) need to resolve the same way as before, so we consider those previous issues (#20582, #20711) as bugs. I'm afraid getBean fall into a different category here where for all modern purposes (programmatic bootstrapping, programmatic wiring, not least of it all Kotlin) we strongly need the non-null semantics.
Thx for the fast response! The problem is not comming from my own code but from the Spring DefaultLifecycleProcessorgetLifecycleBeans method which calls the ctx.getBean(name, type) method and in the case of null-beans throws the BeanNotOfRequiredTypeException.