Thanks anyway :)
I guess integration tests on a real registry will be put on hold for now
then, since the only viable solution is to implement stubs for some
services, which makes me unable to mock and verify their behaviour, which
limits my tests quite a bit...
I find integration testing in Tape
Ah - OK. I don't think there's an easy way to do this at the moment. The
obvious way is to either use the registry with real dependencies or else
create a TestModule to fake the dependencies (but you have already
discounted this approach).
I've been toying with this kind of functionality for T
That's what I'm already doing. This time I wanted to test that the perthread
scope of my service worked like it should, that's why I need to do an
integration test with a real live registry.
On Tue, Feb 23, 2010 at 12:42 PM, Paul Field wrote:
> Hi Inge,
>
> Testify doesn't support overriding ser
Hi Inge,
Testify doesn't support overriding services actually within the repository
(currently, it make components check for overrides before going to the
registry - hence the annotation name @ForComponents).
However, would a simple unit test of the service do the trick for you? In
other word
Ok, so now I need to mock one of the dependencies of a service I'm testing.
I realized that I don't know how to do that when I manually created my
registry. I don't want to have a "TestModule" that builds fakes for my
external dependencies, in this case it is enough to just mock the service
that pr
Hmm, you are right.
The builder method for that service would be called multiple times though IIRC. Maybe somehow check
that then?
Uli
On 17.02.2010 23:32 schrieb Martin Strand:
Hmm, why different instances? Wouldn't every thread see the same proxy
instance?
Martin
On Wed, 17 Feb 2010 12:1
Hmm, why different instances? Wouldn't every thread see the same proxy instance?
Martin
On Wed, 17 Feb 2010 12:17:35 +0100, Ulrich Stärk wrote:
Querying the registry for the same service from different threads should yield
different instances
when using the perthread scope. Just test that. N
I think that should work, yes.
Uli
On 17.02.2010 12:38 schrieb Inge Solvoll:
Ok, thanks!
One more stupid question: Each test method runs in its own thread, right? So
the only place where I need to use Runnable and Thread are inside test
methods that need to test if several threads don't share
Ok, thanks!
One more stupid question: Each test method runs in its own thread, right? So
the only place where I need to use Runnable and Thread are inside test
methods that need to test if several threads don't share the same cached
value? Given that the registry is stored and cached globally in m
Querying the registry for the same service from different threads should yield different instances
when using the perthread scope. Just test that. No need for a request if your service doesn't
require one.
Uli
On 17.02.2010 11:42 schrieb Inge Solvoll:
Hi!
I recently encountered a bug in one
On Wed, 17 Feb 2010 08:42:38 -0200, Inge Solvoll
wrote:
Hi!
Hi!
But how can I test
"perthread" scope on services in the test registry when there are no real
requests? I'm assuming this requires mocking the Request object in some
way?
Only if your service or some of its dependencies us
Hi!
I recently encountered a bug in one of my services, where it had the wrong
scope because I put the scope annotation on the interface rather than on the
implementing class. I got the idea that I could manually create a T5 IOC
registry to do integration testing on my services. But how can I test
12 matches
Mail list logo
