Right but what if you don't want the legacy cdictrl in your cp? ;) 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. 20 juil. 2020 à 15:06, Arne Limburg <arne.limb...@openknowledge.de> a écrit : > > In fact the junit 5 module is implementation independet, except of the > scope feature, which can be done implementation-independently with > Deltaspike, too. > > > 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, 20. Juli 2020 14:36 > An: openwebbeans-dev > Betreff: Re: Mock bean feature for meecrowave > > 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<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: 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://secure.gravatar.com/blavatar/18ef8a5fe8eefd3810b5e9743904d82c?s=200&ts=1595250253 > ]<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> | > > [ > > > https://secure.gravatar.com/blavatar/18ef8a5fe8eefd3810b5e9743904d82c?s=200&ts=1594796380 > > ]<http://rmannibucau.wordpress.com/> > [ > https://secure.gravatar.com/blavatar/18ef8a5fe8eefd3810b5e9743904d82c?s=200&ts=1595250284 > ]<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 > > > > > > 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<http://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< > 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: 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<> > > 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<> > > > 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/> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>> > > > > >> > > > > > > > > > > > > > >