Hi Jeremie, On Dec 10, 2012, at 1:22 PM, jerem <[email protected]> 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

On Dec 10, 2012, at 2:16 PM, Jeremie BOUSQUET <[email protected]> wrote:

Hi Vincent,

2012/12/10 Vincent Massol <[email protected]>

...

Hi Jeremie,

On Dec 10, 2012, at 1:22 PM, jerem <[email protected]> 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