short addition: it looks like you found a portability issue in case of more complex cases -> can you please file a jira-ticket.
fyi: i've pushed a demo of the approach mentioned earlier (see [1]), which doesn't use tricks and therefore it's more predictable in view of (existing and) upcoming versions of owb and weld. regards, gerhard [1] https://github.com/os890/javase-cdi-ds-project-template/tree/mock-registration-event 2017-05-23 14:15 GMT+02:00 Lars-Fredrik Smedberg <[email protected]>: > Hi > > interesting aproach... will play around with it and see how it works... > > regards > lf > > On Tue, May 23, 2017 at 2:05 PM, Gerhard Petracek <[email protected]> > wrote: > > > hi lars-fredrik, > > > > you can inject diff. "sub-producers" (in your test-producer) -> you > > delegate to one of them (just enable one at a time e.g. based on an event > > you fire in your test). > > (you could even provide the sub-producer as payload of the event). > > > > regards, > > gerhard > > > > > > > > 2017-05-23 13:56 GMT+02:00 Lars-Fredrik Smedberg <[email protected]>: > > > > > Hi Gerhard > > > > > > Thanks for the hints... I did play around some with the @Specializes > > > annotation and extending the existing producers and it works nice... > the > > > limitation though is that different test cases within the same test > > module > > > (having the same classpath when run) can not have different specialized > > > implementations... is there a way around that except for using > > > @Exclude(...) as discussed earlier? > > > > > > Regards > > > LF > > > > > > On Tue, May 23, 2017 at 1:15 AM, Gerhard Petracek < > [email protected]> > > > wrote: > > > > > > > hi lars-fredrik, > > > > > > > > in such a case it's usually enough to extend the original bean (but > > keep > > > > the extended bean in the test-classpath) + annotate it with > > @Specializes > > > + > > > > override the producer-methods (+ don't forget to use the same > > annotations > > > > like @Produces). > > > > if you don't like to "couple" both beans that way, you just need the > > > first > > > > @Exclude. the test-producer only needs one if you don't like to move > it > > > to > > > > the test-classpath. > > > > > > > > regards, > > > > gerhard > > > > > > > > > > > > > > > > 2017-05-22 17:19 GMT+02:00 Lars-Fredrik Smedberg <[email protected] > >: > > > > > > > > > Hi Gerhard > > > > > > > > > > I have been playing around some with the ProjectStage to see how it > > > > > works.... if the archive with code being tested have a producer > class > > > > that > > > > > produces beans of type A and I want to use another producer class > to > > > > > produce beans of type A when running my unit tests does that imply > > > that: > > > > > > > > > > - I have to annotate the production code producer class > > > > > with @Exclude(ifProjectStage = ProjectStage.UnitTest.class) AND > > > > > - The unit test producer class with @Exclude(exceptIfProjectStage = > > > > > ProjectStage.UnitTest.class) > > > > > > > > > > ...or is that a bad use-case for using ProjectStage (if so please > > push > > > me > > > > > in the right direction).... if its a good use case for it does it > > then > > > > mean > > > > > I need to annotate all my production producer classes with > > > > > @Exclude(ifProjectStage = ProjectStage.UnitTest.class) to be able > to > > > > allow > > > > > them to be replaced by tests? > > > > > > > > > > Regards > > > > > LF > > > > > > > > > > > > > > > > > > > > On Tue, May 16, 2017 at 1:33 PM, Gerhard Petracek < > > > > > [email protected]> wrote: > > > > > > > > > > > hi lars-fredrik, > > > > > > > > > > > > please use simple java-mechanisms or cdi-mechanisms like events > or > > > > > > ds-mechanisms like the project-stage to enable/disable logic in > > your > > > > > > (test-)classes. > > > > > > you can find simple examples e.g. at [1] + [2] or [3] + [4]. > > > > > > > > > > > > ds is about keeping it simple and close to java- and > cdi-mechanisms > > > > > (since > > > > > > they are enough for most cases). > > > > > > > > > > > > regards, > > > > > > gerhard > > > > > > > > > > > > [1] > > > > > > https://github.com/CDIatWork/IdeaFork/blob/master/ideafork_ > > > > > > core/src/test/java/at/irian/cdiatwork/ideafork/test/core/ > > > > > > InterceptorTest.java > > > > > > [2] > > > > > > https://github.com/CDIatWork/IdeaFork/blob/master/ideafork_ > > > > > > core/src/test/java/at/irian/cdiatwork/ideafork/test/core/ > > > > > > TestMonitoredInterceptorStrategy.java > > > > > > [3] > > > > > > https://github.com/CDIatWork/IdeaFork/blob/master/ideafork_ > > > > > > core/src/test/java/at/irian/cdiatwork/ideafork/test/core/ > > > > EventTest.java > > > > > > [4] > > > > > > https://github.com/CDIatWork/IdeaFork/blob/master/ideafork_ > > > > > > core/src/test/java/at/irian/cdiatwork/ideafork/test/core/ > > > > > > TestIdeaSavedObserver.java > > > > > > > > > > > > > > > > > > > > > > > > 2017-05-16 9:39 GMT+02:00 Lars-Fredrik Smedberg < > > [email protected] > > > >: > > > > > > > > > > > > > Hi > > > > > > > > > > > > > > Is it possible with test-control to tell it to use a different > > > > producer > > > > > > for > > > > > > > a test-case (as I've seen in Weld JUnit Extensions and CDI-Unit > > > where > > > > > you > > > > > > > either cherry pick the classes with the producer you want or > with > > > > > > CDI-Unit > > > > > > > where you can specify a producer to be an alternative > producer). > > > The > > > > > > > samples I've seen mocks the bean being produced rather than > > > > > > > changing/replacing the producer itself... I also see this > config > > in > > > > the > > > > > > > tutorial but I'm not sure what its for: > > > > > > > > > > > > > > allow_mocked_producers > > > > > > > > > > > > > > Regards > > > > > > > LF > > > > > > > > > > > > > > -- > > > > > > > Med vänlig hälsning / Best regards > > > > > > > > > > > > > > Lars-Fredrik Smedberg > > > > > > > > > > > > > > STATEMENT OF CONFIDENTIALITY: > > > > > > > The information contained in this electronic message and any > > > > > > > attachments to this message are intended for the exclusive use > of > > > the > > > > > > > address(es) and may contain confidential or privileged > > information. > > > > If > > > > > > > you are not the intended recipient, please notify Lars-Fredrik > > > > Smedberg > > > > > > > immediately at [email protected], and destroy all copies of > > this > > > > > > > message and any attachments. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Med vänlig hälsning / Best regards > > > > > > > > > > Lars-Fredrik Smedberg > > > > > > > > > > STATEMENT OF CONFIDENTIALITY: > > > > > The information contained in this electronic message and any > > > > > attachments to this message are intended for the exclusive use of > the > > > > > address(es) and may contain confidential or privileged information. > > If > > > > > you are not the intended recipient, please notify Lars-Fredrik > > Smedberg > > > > > immediately at [email protected], and destroy all copies of this > > > > > message and any attachments. > > > > > > > > > > > > > > > > > > > > > -- > > > Med vänlig hälsning / Best regards > > > > > > Lars-Fredrik Smedberg > > > > > > STATEMENT OF CONFIDENTIALITY: > > > The information contained in this electronic message and any > > > attachments to this message are intended for the exclusive use of the > > > address(es) and may contain confidential or privileged information. If > > > you are not the intended recipient, please notify Lars-Fredrik Smedberg > > > immediately at [email protected], and destroy all copies of this > > > message and any attachments. > > > > > > > > > -- > Med vänlig hälsning / Best regards > > Lars-Fredrik Smedberg > > STATEMENT OF CONFIDENTIALITY: > The information contained in this electronic message and any > attachments to this message are intended for the exclusive use of the > address(es) and may contain confidential or privileged information. If > you are not the intended recipient, please notify Lars-Fredrik Smedberg > immediately at [email protected], and destroy all copies of this > message and any attachments. >
