Re: [xwiki-users] Problem mocking LoggerManager
Hi, I could workaround that quite easily, by adding the following in my setUp() method, just before retrieving my class under tests from the component manager: getComponentManager().registerMockComponent(getMockery(), LoggerManager.class); But it seems to confirm that, for any reason, the LoggerManager was not automatically mocked by AbstractBridgedComponentTestCase. BR, Jeremie -- View this message in context: http://xwiki.475771.n2.nabble.com/Problem-mocking-LoggerManager-tp7582812p7582825.html Sent from the XWiki- Users mailing list archive at Nabble.com. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Problem mocking LoggerManager
Hi Jeremie, On Dec 10, 2012, at 1:22 PM, jerem wrote: > Hi, > > I could workaround that quite easily, by adding the following in my setUp() > method, just before retrieving my class under tests from the component > manager: > > getComponentManager().registerMockComponent(getMockery(), > LoggerManager.class); > > But it seems to confirm that, for any reason, the LoggerManager was not > automatically mocked by AbstractBridgedComponentTestCase. This is an old/legacy class and you should try to not use it. That said it extends AbstractComponentTestCase which will register in the CM all annotated components it finds in the CP. The only reason it wouldn't register one component is because it's not in the CP. So either you don't have that dep voluntarily in your pom.xml because it's a runtime dep. You have 2 options: 1) add it as a test dep 2) do what you've done and mock the component. Thanks -Vincent ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Problem mocking LoggerManager
Hi Vincent, 2012/12/10 Vincent Massol > Hi Jeremie, > > On Dec 10, 2012, at 1:22 PM, jerem wrote: > > > Hi, > > > > I could workaround that quite easily, by adding the following in my > setUp() > > method, just before retrieving my class under tests from the component > > manager: > > > > getComponentManager().registerMockComponent(getMockery(), > > LoggerManager.class); > > > > But it seems to confirm that, for any reason, the LoggerManager was not > > automatically mocked by AbstractBridgedComponentTestCase. > > This is an old/legacy class and you should try to not use it. > I'd prefer not, but as I depend on old core I believe there's no alternative ... Or there is ? By the way I'd prefer not depend on old core but DAB was really too limited for my needs. DAB is ok for very specific use, but for heavy modifications on documents and XObjects api is a bit cumbersome. I wrote a component extending DocumentAccessBridge for my own needs, trying to isolate old core to very limited location in my code, but for now it's not "clean". At the end I think I'll be able to remove AbstractBridgedComponentTestCase for my tests completely. > > That said it extends AbstractComponentTestCase which will register in the > CM all annotated components it finds in the CP. > > The only reason it wouldn't register one component is because it's not in > the CP. So either you don't have that dep voluntarily in your pom.xml > because it's a runtime dep. You have 2 options: > 1) add it as a test dep > It's already in xwiki-commons-logging-api, brought by parent xwiki-commons-pom, in scope compile... When you mean not in CP, you mean the component interface (with @Role) or any concrete implementation class ? I tried to add both (xwiki-commons-logging-api and xwiki-commons-logging-logback in scope test) with same result. > 2) do what you've done and mock the component. > Yes I'll stick to that anyway, but I wanted to make sure it was not a symptom of something bad somewhere. > > Thanks > -Vincent > > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > Thanks, Jeremie ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Problem mocking LoggerManager
On Dec 10, 2012, at 2:16 PM, Jeremie BOUSQUET wrote: > Hi Vincent, > > > 2012/12/10 Vincent Massol > >> Hi Jeremie, >> >> On Dec 10, 2012, at 1:22 PM, jerem wrote: >> >>> Hi, >>> >>> I could workaround that quite easily, by adding the following in my >> setUp() >>> method, just before retrieving my class under tests from the component >>> manager: >>> >>> getComponentManager().registerMockComponent(getMockery(), >>> LoggerManager.class); >>> >>> But it seems to confirm that, for any reason, the LoggerManager was not >>> automatically mocked by AbstractBridgedComponentTestCase. >> >> This is an old/legacy class and you should try to not use it. >> > > I'd prefer not, but as I depend on old core I believe there's no > alternative ... Or there is ? Not really... Create a specific bridge for your code so that all the rest of your code can use your bridge interface and be easily tested. Then what remains is just to test the bridge but this can be done in integration or functional testing for example, or with AbstractBridgedComponentTestCase. > By the way I'd prefer not depend on old core but DAB was really too limited > for my needs. DAB is ok for very specific use, but for heavy modifications > on documents and XObjects api is a bit cumbersome. I wrote a component > extending DocumentAccessBridge for my own needs, trying to isolate old core > to very limited location in my code, but for now it's not "clean". At the > end I think I'll be able to remove AbstractBridgedComponentTestCase for my > tests completely. Yes, having your own Bridge is the best idea ATM. >> That said it extends AbstractComponentTestCase which will register in the >> CM all annotated components it finds in the CP. >> >> The only reason it wouldn't register one component is because it's not in >> the CP. So either you don't have that dep voluntarily in your pom.xml >> because it's a runtime dep. You have 2 options: >> 1) add it as a test dep >> > > It's already in xwiki-commons-logging-api, This just defines the LoggerManager interface, not a component implementation so nothing will get registered in the CM. DefaultLoggerManager is in xwki-commons-logging-logback… > brought by parent > xwiki-commons-pom, in scope compile... > When you mean not in CP, you mean the component interface (with @Role) or > any concrete implementation class ? The way it works is that the Component annotation loader will scan the CP for components.txt files and register all components it finds. xwiki-commons-logging-ap doesn't bring a components.txt file with an implementation of LoggerManager... > I tried to add both (xwiki-commons-logging-api and > xwiki-commons-logging-logback in scope test) with same result. xwiki-commons-logging-logback should work but maybe I don't understand your problem… Thanks -Vincent >> 2) do what you've done and mock the component. >> > > Yes I'll stick to that anyway, but I wanted to make sure it was not a > symptom of something bad somewhere. > > >> >> Thanks >> -Vincent ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
