You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Matt Ryan <os...@mvryan.org> on 2016/08/19 00:44:07 UTC

Help with unit tests for JMX stats for S3DataStore

Hi,

I’m working on a patch for Oak that would add some JMX stats for
S3DataStore.  I’m adding code to register a new Mbean in
DocumentNodeStoreService (also SegmentNodeStoreService, but let’s just
worry about the first one for now).

I wanted to create some unit tests to verify that my new JMX stats are
available via JMX.  The idea I had would be that I would simply instantiate
a DocumentNodeStoreService, create an S3DataStore, wrap it in a
DataStoreBlobStore, and bind that in the DocumentNodeStoreService.  Then
with a JMX connection I could check that my Mbean had been registered,
which it should have been by this time.


This was all going relatively fine until I hit a roadblock in
DocumentNodeStoreService::registerNodeStore().  The DocumentMKBuilder uses
a DocumentNodeStore object that I need to mock in order to do the test, and
I cannot mock DocumentNodeStore because it is a final class.  I tried
working around that, but ended up hitting another road block in the
DocumentNodeStore constructor where I then needed to mock a NodeDocument -
again, can’t mock it because it is a final class.


I realize it is theoretically possible to mock final classes using
PowerMock, although by this point I am starting to wonder if all this
effort is a good way to use my time or if I should just test my code
manually.


Is it important that DocumentNodeStore be a final class?  If not, how would
we feel about me simply making the class non-final?  If so, what
suggestions do you have to help me unit test this thing?  I feel that it
should be easier to unit test new code than this, so maybe I’m missing
something.


Thanks


-Matt Ryan

Re: Help with unit tests for JMX stats for S3DataStore

Posted by Chetan Mehrotra <ch...@gmail.com>.
Hi Matt,

It would be easier if you can open an issue and provide your patch
there so that one can have better understanding of what needs to be
tested.

In general we have you can use with MemoryDocumentStore (default used
by DocumentMK builder) and then possibly use Sling OSGi mocks to pick
the registered MBean services. For an example have a look at
SegmentNodeStoreServiceTest which uses OSGi mocks to activate the
service and then pick up the registered services to do the assertion
Chetan Mehrotra


On Fri, Aug 19, 2016 at 6:14 AM, Matt Ryan <os...@mvryan.org> wrote:
> Hi,
>
> I’m working on a patch for Oak that would add some JMX stats for
> S3DataStore.  I’m adding code to register a new Mbean in
> DocumentNodeStoreService (also SegmentNodeStoreService, but let’s just
> worry about the first one for now).
>
> I wanted to create some unit tests to verify that my new JMX stats are
> available via JMX.  The idea I had would be that I would simply instantiate
> a DocumentNodeStoreService, create an S3DataStore, wrap it in a
> DataStoreBlobStore, and bind that in the DocumentNodeStoreService.  Then
> with a JMX connection I could check that my Mbean had been registered,
> which it should have been by this time.
>
>
> This was all going relatively fine until I hit a roadblock in
> DocumentNodeStoreService::registerNodeStore().  The DocumentMKBuilder uses
> a DocumentNodeStore object that I need to mock in order to do the test, and
> I cannot mock DocumentNodeStore because it is a final class.  I tried
> working around that, but ended up hitting another road block in the
> DocumentNodeStore constructor where I then needed to mock a NodeDocument -
> again, can’t mock it because it is a final class.
>
>
> I realize it is theoretically possible to mock final classes using
> PowerMock, although by this point I am starting to wonder if all this
> effort is a good way to use my time or if I should just test my code
> manually.
>
>
> Is it important that DocumentNodeStore be a final class?  If not, how would
> we feel about me simply making the class non-final?  If so, what
> suggestions do you have to help me unit test this thing?  I feel that it
> should be easier to unit test new code than this, so maybe I’m missing
> something.
>
>
> Thanks
>
>
> -Matt Ryan