Hi Arne, Hmm, I see the impl - whatever we do we must use a custom proxy if we want it - but I still fail to see the need for it since it is already trivial to inject a mock per need and use tags to split executions. I also see how it can break mono flavor as mentioned providing a broken container between startup and test method (just use @Observes @Initialized(AppScoped.class) to have a trivial broken setup with this kind of mock). Also keep in mind that in several JUnit5 cases it will not really work as smoothly as it looks like - don't expect to have a method there, you can get 10 tests in the same method but all being independent with dynamic test API or the opposite, you can get a "test scope" which match a full class with @Order, both are not that rare :s.
What is interesting is that it all ends up on not being in meecrowave - so it can let it be releases and the work to be done in owb-junit5[maybe -mock, to refine]. What about creating a small sample on github, defining a few use cases (let's use a "class/uc" even for mono case there) and see how we solve it today and potentially how we would do it better, I'm pretty sure mockito pattern is no more needed today. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 13 juil. 2020 à 11:54, Arne Limburg <arne.limb...@openknowledge.de> a écrit : > 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/> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>> > > >> > > > > >
