Replies: 5 comments 3 replies
-
FYI: https://github.com/cschabl/cdi-unit-junit5 implements synchronization by completely ignoring |
Beta Was this translation helpful? Give feedback.
-
I've added a test to verify the behavior at PR #293. Variants A and D are working as expected. Variant B works as expected. Variant C leads to issues with accessing non-dependent managed beans
I'm going to reflect on it for a couple of days. |
Beta Was this translation helpful? Give feedback.
-
Hi @cschabl , Could you please chime in ? |
Beta Was this translation helpful? Give feedback.
-
After adding more tests (in #299) I see the problem with variant C
Top-level test instance is managed by Weld container which gets shut down after the first test method leads to errors accessing that instance
I will change the implementation so that |
Beta Was this translation helpful? Give feedback.
-
See #316 for more developments. |
Beta Was this translation helpful? Give feedback.
-
JUnit 5 executes individual tests either in isolation (by creating an instance of the test for each method), or using the same test instance for all methods.
See Test Instance Lifecycle for details.
CDI Unit provides similar controls for the lifecycle of the Weld container (
@Isolation
annotation andIsolationLevel
enum).At the moment, these controls are not synchronized, so there are four combinations possible:
@TestInstance(Lifecycle.PER_METHOD)
+@Isolation(IsolationLevel.PER_METHOD)
@TestInstance(Lifecycle.PER_METHOD)
+@Isolation(IsolationLevel.PER_CLASS)
@TestInstance(Lifecycle.PER_CLASS)
+@Isolation(IsolationLevel.PER_METHOD)
@TestInstance(Lifecycle.PER_CLASS)
+@Isolation(IsolationLevel.PER_CLASS)
Let's discuss how useful it is to synchronize these controls - so that only A and D are possible.
Don't we loose some flexibility? Are there any corner cases which make any of the combinations a no-go?
Beta Was this translation helpful? Give feedback.
All reactions