To clarify, Test-Control is a straight up CDI container (with the added feature to control Project stages). You will use the normal features like @Specializes, @Alternative, BeanProvider, @Qualifier and @Exclude.
That with the correct junit suits and application structure you should be pretty much set On 30 April 2014 23:20, 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 >> > >
