But this also needs a new CDI container instance, 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? 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://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 <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> < >>> 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/> >>>> >>>> >>>> >>>> >>>> >>> >>
