deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Li <michael...@gmail.com>
Subject Re: Unit test DeltaSpike Data repositories
Date Wed, 30 Apr 2014 22:03:46 GMT
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 <karl.kilden@gmail.com> 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 <michael.go@gmail.com> 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 <
> > gerhard.petracek@gmail.com> 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 <michael.go@gmail.com>:
> > >
> > > > 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 <
> > > > gerhard.petracek@gmail.com> 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 <michael.go@gmail.com>:
> > > > >
> > > > > > 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message