felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dawid Loubser <da...@travellinck.com>
Subject Re: testing a service, mocking dependencies
Date Tue, 16 Sep 2014 15:21:51 GMT
The manner in which you inject dependencies in your unit test should be
exactly the same as when you deploy the component to a production
environment.

If you inject into fields in production, you should inject into fields
in your test also.
If your fields are private, and you're running DI framework that
overcomes that in production, just use the same framework in your test.
Otherwise, remove the 'private' keyword from the fields (making them
package-scope), which means your unit test can directly set them.

Private is not Private in Java (otherwise your DI framework wouldn't be
able to inject directly into them in anyway). Just don't worry about it.
Don't code objects to protect them from being hacked by other objects
deployed in the same (trusted) environment - practical security doesn't
work that way.

"Pollution of state" does not apply during object construction / setup,
only during use by clients, which should be limited to using the object
as per its interface in anyway.

Enjoy OSGi - it's lovely,
Dawid Loubser


On 16/09/2014 17:13, Neil Bartlett wrote:
> Why not just create a setter method for this dependency and use that from the unit test?
I've never understood the desire to inject directly into private fields.   
>
> I also didn't understand your explanation about polluting state. What does the state
matter if this is a genuine unit test?
>
> Regards,
> Neil
>
> --  
> Neil Bartlett
> Sent from a phone
>
>
> On Tuesday, 16 September 2014 at 15:31, Konstantine Kougios wrote:
>
>> 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" <david_jencks@yahoo.com.INVALID> 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
>>> <Konstantine.Kougios@akqa.com> 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" <david.bosschaert@gmail.com>
>>>> 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
>>>>> <Konstantine.Kougios@akqa.com> 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: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>  
>>>>  
>>>>  
>>>>  
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>  
>>>  
>>>  
>>>  
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>  
>>  
>>  
>>  
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>  
>>  
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message