Hi Arne, We integrate with junit in a "natural" way, ie we dont switch the way the test class is intantiated which can break some other extensions if a proxied instance is used (big drawback of using cdi beans for tests cause you can scope them or worse, use interceptors) or not be as deterministic as it must be if order of extensions has not cdi first.
About the mocking here are some thoughts: 1. I wouldnt do a mockito extension, I still fail to see the value even for remote systems - we can discuss it in another thread if you think it is not just a habit 2. Mocking a bean is mainly about vetoing one and adding another one, this is mainly about adding an extension so: 2.a. for mono flavor it is about writing an extension, that's it 2.b. for per class flavor, it is about registering an extension just for the class - or make it ignored/noop for others. It can be done with overriding extension loader in owb properties but i guess a @ClassCDIExtension on static fields can a good option too without having to play with container config Side note: mock alternative is an example of stereotype but im not sure it is the best way to impl mocking (it was thought reversed IMHO) Once we have 2.b - only for per class flavor - we can have a new module providing a built in extension without the spi registration to be per class friendly if still needed (think anonymous extension is a good enough solution and avoids a new api layer). Wdyt? Le dim. 12 juil. 2020 à 08:56, Arne Limburg <arne.limb...@openknowledge.de> a écrit : > Hi guys, > > > I am prototyping a bean mocking feature for the test-module. > > The basic idea is to have an @MockBean annotation that is an @Alternative > @Stereotype and is enabled by the test module. > > The basic features works nearly out of the box (see > https://github.com/ArneLimburg/openwebbeans-meecrowave-examples/blob/mock/junit5-mock/src/test/java/com/superbiz/jaxrs/HelloEndpointTest.java > ). > > The drawback of this small solution is, that the @MockBean has to be > static and that we cannot have the same @MockBean definied in two tests > (haven't tested that, but I guess we would have an > AmbiguousResolutionException in that case). > > > So here is what I would like to do: > > - Introduce a @TestClassScoped and @TestMethodScoped and make @MockBean > @TestMethodScoped > > - Make every test class a CDI bean such that @Produces @MockBean fields > are collected (Does anyone know why we don't did that in the first place)? > > - Maybe (in a next step) directly add support for Mockito mocks or > otherwise be sure, that our extension plays well together with the > MockitoExtension > > > Any objections to go ahead with that? > > > I have no Idea how this could work with the @MonoMeecrowaveConfig. > > > Any ideas on that? > > > Cheers, > > Arne > > OPEN KNOWLEDGE GmbH > Poststraße 1, 26122 Oldenburg > Mobil: +49 151 - 108 22 942 > Tel: +49 441 - 4082-154 > Fax: +49 441 - 4082-111 > arne.limb...@openknowledge.de > www.openknowledge.de <https://www.openknowledge.de/> > > Registergericht: Amtsgericht Oldenburg, HRB 4670 > Geschäftsführer: Lars Röwekamp, Jens Schumann > > Treffen Sie uns auf kommenden Konferenzen und Workshops: > > Zu unseren Events<https://www.openknowledge.de/event/> > > > > >
