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/> >> > >> > >> > >> > >> > >> >
