Not sure it helps but in tomee we have a mockito extension ( https://github.com/apache/tomee/blob/master/utils/openejb-mockito/src/test/java/org/apache/openejb/mockito/MockitoAndAppComposerTest.java - blame me to have thought it would be a good idea) and we can actually make it working differently with junit: each test field can get a @CdiInject - or a better name - and if marked as such it becomes a CDI bean. This way mockito stay wired naturally with mockito extension and we make it working in cdi. No need of anything specific in our codebases. I suspect it can land in owb-junit5 and be reused in mw - rather than the opposite due to deps.
maybe something to play with, nice thing about it is that if you have a @RegisterExtension MyTestContainer container; then you can make it a bean too and easily wire some conf through a test bean instead of doing it in all your tests if not using mono feature. 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 à 08:14, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit : > > > 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://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/> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>> >> >> >> >>
