deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: Unit test DeltaSpike Data repositories
Date Mon, 05 May 2014 17:10:22 GMT
hi michael,

i haven't tested your use-case, however, you can have a look at [1].

regards,
gerhard

[1]
http://os890.blogspot.com/2014/05/add-on-mock-cdi-beans-with-deltaspike.html



2014-05-03 1:02 GMT+02:00 Michael Li <michael.go@gmail.com>:

> I solved the problem by separating the repositories into another
> sub-project, where I run JUnit with "Test-Control", and the project with
> CDI beans is still tested using CDI-Unit. It's not perfect, but at least
> working now.
>
>
> On Thu, May 1, 2014 at 1:10 AM, Karl Kildén <karl.kilden@gmail.com> wrote:
>
> > I keep forgetting you can't disable the repositories like this :-) (at
> > least I don't know how) Not sure if there's some trick or you need a
> > separate module with only a dependency to data-api for mocked tests.
> Could
> > ofc require some maven trickery to get working.
> >
> > Otherwise the tests with mocks can always be plain Mockito I guess.
> >
> >
> > On 1 May 2014 10:05, Karl Kildén <karl.kilden@gmail.com> wrote:
> >
> > > 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
> > >>
> > >
> > >
> >
>
>
>
> --
> Michael Li
>

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