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