One small addition:
There are at least two typical use cases i have in mind:
1. is yours, replacing a service with a mock instance.
2. tracing service interaction. So the real service is still executed but
you want, at the end of the day check if certain services have been called,
what the parameters where and what they returned and so on like so:
expect(service(MyService.class).with(String.class).value("foo").returnException(RuntimeException.class));I think both can be directly supported in Exam if we can decide WHAT to replace. So, in hard core OSGi applications the unit of thinking is OSGi Service. Observing the Service Registry and Hooks will get you all the information. It just is worth to think about other behavior that is ongoing and you might want to observe. The user might use his in IoC framework that does not publish every service to the registry (maybe just a few global ones). So we should keep in mind to give 3rd parties the ability participate in this test/mock framework via some less obtrusive (but standard) way. I have the OSGi Event service in mind. So instead of (or additionally to) directly hanging into the Service Registry, listening to Events and evaluating those provides a easy to implement way for 3rd parties. This is just interesting for scenario 2 of the above listing. But its a scenario i've seen in the real world - so its worth to be supported. wdyt ? Toni On Wed, Jul 27, 2011 at 9:22 AM, Toni Menzel <[email protected]> wrote: > i know what you mean ;) > The idea i have in mind is to wrap mockito behavior (that you write) right > into the classes you add into you tiny bundles. > There is only one problem, you usually don't have control over the classes > created and there is no standard way to get hold of the mock instance, so > you can verify.That can be solved. > Whats really going to be neat is how and WHERE you define the mock > behavior: > when(mock.doThat()).thenReturn(foo); > and WHERE you do the verification. > > This is especially tricky if you really want to do this in your own > tinybundles bundle because what you do in @Configuration happens OUTSIDE and > BEFORE the osgi framework instance. So you can just be declarative, not > passing any instances into the future. > > What will be much simpler, and has been done before, to use the @Test phase > itself, where everything happens inside OSGi already. So in short: > @Test public void testMe() { > MyService service = mock(MyService.class); > // add mock behavior > ctx.registerService(MyService.class,service,null); > // execute code under test > > // verify mock > } > > Once we have boiled out the phases that are typical for such scenarios, i > am sure we can add "native" support for it in Exam to distinguish those > phases in their own callback methods like so: > @PrepareMocks > public void prepare(BundleContext ctx) > > @VerifyMocks > //optionally, fine grained service selection: > @Service (filter="&(objectId=MyService.class)(company=foo)") > public void verify(MyService mocked) > > anyway, this is syntactic sugar that we should align with a more user > friendly service interaction (like not requiring you to interact with Bundle > Context directly but just inject services into the places you need them to > be. > > Having the entire behavior in tiny bundles is not much harder than just > writing the classes that do the mocking (or use dynamic proxy + mockito) but > the thing is how this can interact with you test. > For sure, if you KNOW that you are facing a service that is INFACT a mock, > you can directly use it and treat it like one. > The real thing we need to add in Tinybundles in that case is some simpler > way of adding mock replacements of classes. > I will look into this perhaps today if i get to solve another issue in > 2.2.0. If not, there will be plenty of time to think about it as i will be > on a 4 week leave tomorrow. > > All in all, Tinybundles codebases is really small, so its worth maybe > trying to add it yourself (?). Dynamic Proxy+Mockito are could combinations > to implement that i think. > > > On Wed, Jul 27, 2011 at 12:17 AM, Rodolfo Barbeiro < > [email protected]> wrote: > >> Hi Toni, >> >> These examples help. >> >> Answer me one question, you can add behavior mock-classes? (Similar to >> objects >> created by EasyMock.) >> >> See my test scenario: >> >> My bundle (which will be tested) depends on other bundles. I want to simulate >> these bundles using TinyBundles.(ok?) >> But these bundles need to expose OSGI services and simulate behavior. For >> when my bundle-test invoke the services, they have to respond as previously >> defined. >> >> Do you understand? >> >> Is there a way to do this? >> >> >> Regards, Rodolfo Barbeiro >> >> >> ------------------------------ >> Date: Tue, 26 Jul 2011 23:47:37 +0200 >> Subject: Re: Pax-Exam: How to create bundle mocks using tinybundles? >> From: [email protected] >> To: [email protected] >> >> >> You can also have a quick look at pure tiny bundles examples: >> http://team.ops4j.org/wiki/display/ops4j/Tinybundles >> >> Or at a very recent use case from Neo4J (using Exam + Tinybundles) : >> >> https://github.com/neo4j/neo4j-osgi/blob/master/examples/src/test/java/org/neo4j/examples/osgi/OSGiTest.java >> >> I am adding dedicated examples for TB in the Exam-Learn Project once 2.2.1 >> is out (which will contain a crucial isolation bug fix in NativeContainer) >> >> hope this helps ? >> Toni >> >> On Tue, Jul 26, 2011 at 10:19 PM, Andreas Pieber <[email protected]>wrote: >> >> Please take a look at the pax wicket integration tests. I do it there. On >> mobile so no direct link but it's also on github.com/ops4j in the itest >> project >> Kind regards Andreas >> On Jul 26, 2011 6:58 PM, "Rodolfo Barbeiro" <[email protected]> >> wrote: >> > >> > >> > >> > >> > Hi Everyone! Does anyone have an example or can tell me how I can create >> bundles mocks using tinybundles? Thanks! Rodolfo Barbeiro. >> >> _______________________________________________ >> general mailing list >> [email protected] >> http://lists.ops4j.org/mailman/listinfo/general >> >> >> >> >> -- >> Toni Menzel Source <http://tonimenzel.com> >> >> >> _______________________________________________ general mailing list >> [email protected] http://lists.ops4j.org/mailman/listinfo/general >> >> _______________________________________________ >> general mailing list >> [email protected] >> http://lists.ops4j.org/mailman/listinfo/general >> >> > > > -- > Toni Menzel Source <http://tonimenzel.com> > > -- Toni Menzel Source <http://tonimenzel.com>
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
