Setter is ok, provided the bean is visible via an interface to other bundles. But it can create issues on bigger projects with lots of developers. I.e. A developer can use the setter to change the field on production code with disastrous results. Or even on test code that runs inside the container, which means subsequent tests that use the bean/service will fail because the service is in corrupted state. On the other hand, the forTesting(B b) is harmless as it returns a new instance and it’s method implies it should be used only for testing. Even if it is used in production code, it’s side effects will be limited to the code calling forTesting().
Injecting via reflection can help avoid the setter & forTesting - after all those are only for test cases and not for production code and reflection will only be used for testing. I am not saying it’s the best approach, but I.e. Mockito can do that via @InjectMock and it looks pretty tidy way of doing that and production code remains clean of testing artifacts. http://docs.mockito.googlecode.com/hg/latest/org/mockito/InjectMocks.html Spring framework allows creation of non-mocked beans via separate application configuration xml files, which comes handy sometimes when we want to unit test using real objects. I suppose the best approach would be to use mockito, @InjectMocks when I want to test using mocks. And forTesting() can be used when we need to inject non-mock dependencies, for unit tests that prefer to use real objects. On 16/09/2014 16:13, "Neil Bartlett" <[email protected]> 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" <[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] >> >> > >
