deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Kildén <karl.kil...@gmail.com>
Subject Re: Unit test DeltaSpike Data repositories
Date Wed, 30 Apr 2014 21:20:01 GMT
@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
>

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