I want to write a unit test which will run outside of the container. I
want to mock dependencies. I don’t mind about lifecycle methods as my
service won’t use them (or I don’t need / can mock them).
Say for example I am writing A that uses B which downloads a big json file
from the internet. I want to unit test it by mocking B so to avoid the
download:
@Service
Class A {
@Reference private B b;
public void doSomething() {
V v=b.download();
…. use v
}
Public static A forTesting(B b){
A a=new A();
A.b=b;
Return a;
}
}
…. And then
Public class Atest {
@Test
Public void testDoSomething() {
B b=mock(B.class);
When(b.download()).return(“file”);
A a = A.forTesting(b);
A.doSomething….
}
}
Setters would be similar to the above but does felix/osgi provide a more
transparent way (I.e. Via reflection)?
On 16/09/2014 15:22, "David Jencks" <[email protected]> wrote:
>You don't provide enough information to know what you are doing, and I
>don't understand what you mean by a unit test.
>
>If you are writing a DS component and using Felix DS annotations, note
>that the @Reference on a field without accessors results in byte code
>generation of accessor methods. You might want to write them yourself.
>
>Is your "unit test" running in a DS container?
>
>If not, then you need to simulate the calls to the event
>(bind/updated/unbind) and lifecycle (activate/modified/deactivate)
>methods that the container will make in your unit test. After all the
>"stop" methods (deactivate and unbind) are called, the container will
>discard the component instance.
>
>If you are running in a DS container then register your B as a service
>and the container will take care of calling the (generated, with your
>current code)bind/unbiind methods.
>
>LIke every other component framework that accesses apparently invisible
>members during runtime, DS calls setAccessible internally so it can
>access them. The spec may support field injection in the future and it
>will be supported using setAccssible pretty much exactly as David B.
>suggests.
>
>david jencks
>
>On Sep 16, 2014, at 6:59 AM, Konstantine Kougios
><[email protected]> wrote:
>
>> Well, that¹s similar to the forTesting factory I mention but with the
>> drawback that the state of A is corrupted until the JVM terminates. By
>> corrupted I mean that my mock will be part of A until either the jvm
>>stops
>> or something else injects a different thing to A.b. If the mock is set
>> this way while running in-container tests, A state is corrupted.
>>
>>
>> On 16/09/2014 14:56, "David Bosschaert" <[email protected]>
>>wrote:
>>
>>> Why not set the field b in your object manually to the mock B for unit
>>> testing?
>>>
>>> Just assign it to the field. If you insist on having it private you
>>> can call 'Field.setAccessible(true)' in your unit test and assign it
>>> using reflection...
>>>
>>> Best regards,
>>>
>>> David
>>>
>>> On 16 September 2014 14:39, Konstantine Kougios
>>> <[email protected]> wrote:
>>>> Hi, say I got a service A, which has a
>>>>
>>>> @Reference private B b;
>>>>
>>>> Now I want to write a unit test and mock B, how can I inject the
>>>>mocked
>>>> dependency?
>>>>
>>>> Only reasonable thing I found so far is to have a static factory
>>>>method
>>>> on A, public static A forTesting(B b) { Š }
>>>>
>>>> Thanks,
>>>>
>>>> Kostas
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [email protected]
>For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
