Le lun. 20 juil. 2020 à 12:54, Arne Limburg <arne.limb...@openknowledge.de> a écrit :
> I've coded a small mocking extension for CDI: > https://github.com/ArneLimburg/cdimock > It is completely independent of any CDI implementation, so I'm not sure if > we should put it into OWB or Meecrowave. > Wdyt? > Or maybe putting it into Deltaspike. > Hmm, didnt think of it but DS sounds fair. > I recognized, that Deltaspike does not have any JUnit 5 support for now. > Is there a reason not putting the owb-junit5 module to Deltaspike? > There is a ticket about DS junit support to be integrated with junit5 AFAIK, maybe time. That said, junit5 module is a thin layer on top of CDI-SE so fits not bad OWB + its scope feature integrates with OWB SPI. > > 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: Arne Limburg > Gesendet: Mittwoch, 15. Juli 2020 09:09 > An: dev@openwebbeans.apache.org > Betreff: AW: Mock bean feature for meecrowave > > OK, > > I see your point and discussed this with Mark at monday evening. I'll code > an example to discuss the different cases. Then we can see what to include > into Meecrowave or OWB Test. So I don't think, we'll put anything of that > in the next release. > > I have found one minor issue I'll report and fix. And then I am fine with > a release. > > Cheers, > Arne > > ________________________________ > Von: Romain Manni-Bucau <rmannibu...@gmail.com> > Gesendet: Montag, 13. Juli 2020 12:18 > An: openwebbeans-dev > Betreff: Re: Mock bean feature for meecrowave > > 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> | > [ > https://secure.gravatar.com/blavatar/18ef8a5fe8eefd3810b5e9743904d82c?s=200&ts=1594796380 > ]<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 > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > [ > https://www.packtpub.com/media/catalog/product/cache/5d165500a520a389deb95b325792ea25/b/0/b08602_cover_0.png > ]< > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > Java EE 8 High Performance< > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > www.packtpub.com > Get more control of your applications performances in development and > production and know how to meet your Service Level Agreement on critical > microservices. > > > > > 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<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: 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=1594796471 > ]<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://secure.gravatar.com/blavatar/18ef8a5fe8eefd3810b5e9743904d82c?s=200&ts=1594633142 > > ]<http://rmannibucau.wordpress.com/> > [ > https://secure.gravatar.com/blavatar/18ef8a5fe8eefd3810b5e9743904d82c?s=200&ts=1594796471 > ]<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 > > > > > > 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< > 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/> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> ________________________________ > > > >>> 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<> > > 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/> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>> > > > >> > > > > > > > > >
