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 Thu, 01 May 2014 08:05:40 GMT
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 <michael.go@gmail.com> 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 <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