OK, But per test case / suit with Test-Control it is possible to set ProjectStage [1]. You can create a custom project stage and use it. Then your mock can be project stage activated with @Exclude [2]. See [3] for code example
http://deltaspike.apache.org/projectstage.html [1] http://deltaspike.apache.org/core.html#exclude [2] [3] @TestControl(projectStage = MockTest.class) @Exclude(exceptIfProjectStage = MockTest.class) public class MyMock implements DeltaspikeRepository{} On 1 May 2014 00:03, Michael Li <[email protected]> wrote: > Hi Karl, > > Thanks for your reply. I guess you misunderstood my testing scenario. Let > me make it more clear. > > * Main source: > > class A { > @Inject B b; > } > > class B {} > > > * Test source: > > class ATest { > @Inject A a; > > // I want inject this B mock into A > @Produces @Mock // @Mock is Mockito annotation > B b; > } > > class BTest { > @Inject B b; // my real B impl > } > > The problem is that the container see two B instances: one from main source > and another from the mock from testA. > I know it shall work with some configuration as CDI-Unit does. However, > CDI-Unit can not inject data repositories. > > > > On Wed, Apr 30, 2014 at 2:20 PM, Karl Kildén <[email protected]> > wrote: > > > @MyQualifier > > @Inject > > MyMock myMock > > > > Why make it hard for yourself? > > > > TestControl, @Exclude and different suits and project stages would be one > > way also. > > > > Couldn't you also use BeanProvider to get the mock? > > > > For my app the tests that needs the real backend are in the jar with all > > logic. They either need injects and real backends etc or I only need > JUnit > > and mockito. > > > > My web logic does not need db logic for tests so I have mocks with just > > static entities. But here and there real backend is needed so I use mocks > > with @Mock qualifier > > > > > > > > On 30 April 2014 22:04, Michael Li <[email protected]> wrote: > > > > > Those looks like global setting to me. In my unit tests scenario, for > > > example, class A has an association with class B, > > > > > > In unit test class ATest, I like to inject the real A and mocked B > > > (produced in ATest class). > > > In unit test class BTest, I need inject the real B (not the mocked) in > > > order to test it. > > > > > > How does the container know when I need a real and when I need a > mocked? > > > Does the scope (e.g. RequestScope) help here? For example, set the > > mocked B > > > produced in BeanA in "RequestScope". > > > > > > Thanks. > > > > > > > > > On Wed, Apr 30, 2014 at 12:45 PM, Gerhard Petracek < > > > [email protected]> wrote: > > > > > > > hi michael, > > > > > > > > you can use std. cdi mechanisms like @Alternative beans for your > mocks. > > > > just add and configure them in your test-module. > > > > or use @Exclude(exceptIfProjectStage = ProjectStage.UnitTest.class) > > > > with that many projects could drop special mocking frameworks at all. > > > > > > > > regards, > > > > gerhard > > > > > > > > http://www.irian.at > > > > > > > > Your JSF/JavaEE powerhouse - > > > > JavaEE Consulting, Development and > > > > Courses in English and German > > > > > > > > Professional Support for Apache MyFaces > > > > > > > > > > > > > > > > 2014-04-30 21:20 GMT+02:00 Michael Li <[email protected]>: > > > > > > > > > Hi Gerhard, > > > > > > > > > > Thanks for the reply. > > > > > > > > > > I did try the built-in test control. However it doesn't play well > > with > > > > mock > > > > > framework like "Mockito". Basically the CDI container get confused > > > > between > > > > > a mocked bean and the real bean from my production code. I don't > know > > > how > > > > > CDI-Unit solve the ambiguity, but the built-in test control didn't > by > > > > > default. If the built-in test control can work with mock with some > > > > > configuration, I'd love to go with it. > > > > > > > > > > Michael. > > > > > > > > > > > > > > > On Wed, Apr 30, 2014 at 12:08 PM, Gerhard Petracek < > > > > > [email protected]> wrote: > > > > > > > > > > > hi michael, > > > > > > > > > > > > you could try [1] instead. > > > > > > > > > > > > regards, > > > > > > gerhard > > > > > > > > > > > > [1] http://deltaspike.apache.org/test-control.html > > > > > > > > > > > > > > > > > > > > > > > > http://www.irian.at > > > > > > > > > > > > Your JSF/JavaEE powerhouse - > > > > > > JavaEE Consulting, Development and > > > > > > Courses in English and German > > > > > > > > > > > > Professional Support for Apache MyFaces > > > > > > > > > > > > > > > > > > 2014-04-30 20:24 GMT+02:00 Michael Li <[email protected]>: > > > > > > > > > > > > > We're currently using CDI-Unit for CDI components testing. > > > However, I > > > > > > can't > > > > > > > inject my data repository (interface) into my unit test > classes. > > I > > > am > > > > > > > wondering if there is anything special to setup (to work with > > > > CDI-Unit) > > > > > > or > > > > > > > other approach to unit test repository. The exception I got is > > > pasted > > > > > as > > > > > > > below. > > > > > > > > > > > > > > > > > > > > > org.jboss.weld.exceptions.DeploymentException: WELD-001408: > > > > Unsatisfied > > > > > > > dependencies for type DomainRepository with qualifiers @Default > > > > > > > at injection point [UnbackedAnnotatedField] @Inject > > > > > > > > com.acme.server.repository.DomainRepositoryTest.domainRepository > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > com.acme.server.repository.DomainRepositoryTest.domainRepository(DomainRepositoryTest.java:0) > > > > > > > > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:368) > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289) > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135) > > > > > > > at > > > > > > org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166) > > > > > > > at > > > > org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514) > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68) > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66) > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60) > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53) > > > > > > > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > > > > > > > at java.lang.Thread.run(Thread.java:745) > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > -- > > > > > > > Michael Li > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Michael Li > > > > > > > > > > > > > > > > > > > > > -- > > > Michael Li > > > > > > > > > -- > Michael Li >
