Hi,
I just had a call with Mark and we discussed solutions for the mono flavor. We came up with the following idea: In an extension we collect all types to mock (we get all the testclasses via ProcessAnnotatedType) and later in ProcessInjectionPoint we add an @Mock qualifier to any injection point that is assignable to any of the mock types. We than can add @TestMethodScoped @Mock beans that delegate either to the real (@Default) instance or return a mock response, depending on a check, that detects if a mock was configured in the test-method or not. If we tie the implementation to Mockito we can detect that via a MockCreationListener or so. If we do not want to tie us to Mockito, we can think about a build-in Bean Mock<MyServiceToMock> that can be injected into a test to enable or disable mocking. For the per class flavor we can do the same, but restrict the processing to mocks defined in that specific test class. A solution thats works without tying to Mockito, but integrating smoothly would be very cool. 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/> ________________________________ Von: Romain Manni-Bucau <rmannibu...@gmail.com> Gesendet: Montag, 13. Juli 2020 08:14 An: openwebbeans-dev Betreff: Re: Mock bean feature for meecrowave Le lun. 13 juil. 2020 à 08:06, Mark Struberg <strub...@yahoo.de.invalid> a écrit : > But this also needs a new CDI container instance, right? > Not new as we already have it working right now - or I didnt get it right. > > I've created mocking for one of my meecrowave projects a few years back > (hell, time flies). > That's why I introduced the custom ClassLoader sitting in the middle. > > Basically we have 2 options to handle mocking: > > a.) Bootstrap the container once and have a 'manual proxy' which delegates > to different instances based on which unit test you are running in. > > b.) Bootstrap the container once for each unit test which requires some > special mocking scenario. > > Is this the discussion we are having right now, or did I get something > wrong? > Don't think so. Current status is: 1. we have the mono flavor which provides a consistent deployment for all tests. 2. the per class flavor provides a deployment per class. My opinion is that: 1. We must not enable to switch the mock per test or even class cause it breaks the contracts and does not go through the validations and callbacks (postconstruct etc) back so it breaks easily a deployment silently and can lead to false positives. It can also prevent the use of mock (startup init) compared to overriding the bean with a real bean or a decorator or interceptor. 2. This already supports mocking. So personally I think we should refine the mock needs and particularly what we are missing. Maybe we should create a GH sample project? > > LieGrue, > strub > > > > Am 12.07.2020 um 18:12 schrieb Romain Manni-Bucau <rmannibu...@gmail.com > >: > > > > PS: reviewing some personal projects I found another simpler way to > handle > > mocking of beans: scanningIncludes/excludes. Just excludes the bean to > mock > > and include (if not the case by default) the mock bean or its producer > and > > voilà :). > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < [https://secure.gravatar.com/blavatar/18ef8a5fe8eefd3810b5e9743904d82c?s=200&ts=1594633142]<http://rmannibucau.wordpress.com/> New posts here >>> rmannibucau.metawerx.net | New posts here >>> https://rmannibucau.metawerx.net<http://rmannibucau.wordpress.com/> rmannibucau.wordpress.com New posts here >>> https://rmannibucau.metawerx.net > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > Le dim. 12 juil. 2020 à 13:42, Romain Manni-Bucau <rmannibu...@gmail.com> > a > > écrit : > > > >> > >> > >> Le dim. 12 juil. 2020 à 12:42, Arne Limburg < > arne.limb...@openknowledge.de> > >> a écrit : > >> > >>> Hi Romain, > >>> > >>> > >>> I don't understand your case 2.a. Even for mono flavor I would like to > >>> define per test, which bean to mock and for which bean to take the real > >>> instance. I have no idea how to do this with a simple extension. > >>> > >> > >> > >> Mono instance means a single container for all test methods and config > is > >> global so whatever you do beans are jvm bounds. > >> Indeed you can use request scope to make it method scoped (thanks > request > >> scope controller) orthrough just a simple proxy and global static var > but > >> it is not the intent of the mono runner which really provides a context > for > >> all tests - does not prevent to have N executions though. > >> > >> Customization per test is the not the mono runner but the class one > IMHO. > >> > >> I know with owb-se i tend to make none the scanning of test module and > add > >> to @Cdi(reusable=false, classes=MyMock.class) the overriden beans. > Since mw > >> supports cdise api it should work too and does not require any api > buthave > >> to admit i like the extension customization which enables more use cases > >> and optimizations IMO. > >> > >> Hope it makes sense > >> > >> > >> > >>> > >>> For 2.b. an extension that is registered per class sounds reasonable. > >>> I'll give it a try. > >>> > >>> > >>> 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<http://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/> > >>> > >>> > >>> > >>> > >>> > >>> ________________________________ > >>> Von: Romain Manni-Bucau <rmannibu...@gmail.com> > >>> Gesendet: Sonntag, 12. Juli 2020 09:56 > >>> An: openwebbeans-dev > >>> Betreff: Re: Mock bean feature for meecrowave > >>> > >>> 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<http://www.openknowledge.de<http://www.openknowledge.de<http://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/> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >> > >
