Grokbase › Groups › HBase › dev › February 2012
FAQ
Benoit's comment is directly related to our practice, especially when we
add new methods which are only called by unit tests.

FYI

---------- Forwarded message ----------
From: tsuna <tsunanet@gmail.com>
Date: Wed, Feb 22, 2012 at 9:13 AM
Subject: Re: asynchbase-1.2.0-rc1 is available for download
To: Jim Scott <jim@13ways.com>
Cc: AsyncHBase <asynchbase@googlegroups.com>

On Wed, Feb 22, 2012 at 8:50 AM, Jim Scott wrote:
I ask because I am writing some unit tests to make sure that my code is
working properly and I cannot mock the HBaseClient because it is final. I
completely understand the rationale to make it final, but without it
implement an interface or being non-final I cannot mock the object.
Hi Jim,
OpenTSDB has unit tests that are mocking out HBaseClient just fine
[1]. You can mock out pretty much anything on the JVM: final,
private, JDK stuff, etc. All you need is the right tools. I've been
very happy with PowerMock. It supports Mockito and EasyMock.

I've never been keen on mutilating public interfaces for the sake of
testing. With tools like PowerMock, we can keep the public APIs tidy
while mocking and overriding anything, even in the most private guts
of the classes.

[1]
https://github.com/stumbleupon/opentsdb/blob/master/src/uid/TestUniqueId.java#L66

--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com

Search Discussions

  • Jesse Yates at Feb 22, 2012 at 5:29 pm ⇧
    I put forward rolling in Powermock a while back, but it always seems a bit
    overkill for just one or two methods. However, if we make using powermock a
    'best practice' going forward, then it becomes reasonable.

    Powermock is really nice in that not only can you access private methods
    and mock final objects, you can always set private fields and move out
    builtin in classes (eg. System, Integer, etc). Pretty sweet.

    Only long standing problem I've found with it is that, by necessity, almost
    everything is done via reflection, so method names to (power)mock need to
    be passed as strings, which can be annoying (but not hard) to maintain.

    +1 on adding in powermock as a best practice and updating the book to say
    so.

    Just my $0.02

    -------------------
    Jesse Yates
    240-888-2200
    @jesse_yates
    jyates.github.com

    On Wed, Feb 22, 2012 at 9:23 AM, Ted Yu wrote:

    Benoit's comment is directly related to our practice, especially when we
    add new methods which are only called by unit tests.

    FYI

    ---------- Forwarded message ----------
    From: tsuna <tsunanet@gmail.com>
    Date: Wed, Feb 22, 2012 at 9:13 AM
    Subject: Re: asynchbase-1.2.0-rc1 is available for download
    To: Jim Scott <jim@13ways.com>
    Cc: AsyncHBase <asynchbase@googlegroups.com>

    On Wed, Feb 22, 2012 at 8:50 AM, Jim Scott wrote:
    I ask because I am writing some unit tests to make sure that my code is
    working properly and I cannot mock the HBaseClient because it is final. I
    completely understand the rationale to make it final, but without it
    implement an interface or being non-final I cannot mock the object.
    Hi Jim,
    OpenTSDB has unit tests that are mocking out HBaseClient just fine
    [1]. You can mock out pretty much anything on the JVM: final,
    private, JDK stuff, etc. All you need is the right tools. I've been
    very happy with PowerMock. It supports Mockito and EasyMock.

    I've never been keen on mutilating public interfaces for the sake of
    testing. With tools like PowerMock, we can keep the public APIs tidy
    while mocking and overriding anything, even in the most private guts
    of the classes.

    [1]

    https://github.com/stumbleupon/opentsdb/blob/master/src/uid/TestUniqueId.java#L66

    --
    Benoit "tsuna" Sigoure
    Software Engineer @ www.StumbleUpon.com
  • Ted Dunning at Feb 22, 2012 at 9:26 pm ⇧
    Actually jmockit uses byte code patching so you may suffer less reflection overhead than expected. My guess is that powermock is doing something quite similar.

    Sent from my iPhone
    On Feb 22, 2012, at 9:29 AM, Jesse Yates wrote:

    Only long standing problem I've found with it is that, by necessity, almost
    everything is done via reflection, so method names to (power)mock need to
    be passed as strings, which can be annoying (but not hard) to maintain.

    +1 on adding in powermock as a best practice and updating the book to say
    so.
  • Tsuna at Feb 22, 2012 at 8:25 pm ⇧

    On Wed, Feb 22, 2012 at 9:23 AM, Ted Yu wrote:
    Benoit's comment is directly related to our practice, especially when we
    add new methods which are only called by unit tests.
    I didn't dare to say it, but now that you do… :P

    HBase exposes a TON of implementation details in public APIs. Makes
    things harder to refactor because you don't know if anyone out there
    is relying on this method or extending that class.

    Mocking out things that are hidden is certainly a bit harder than
    calling into a public API javadoced as "for test only", but if it
    keeps the APIs clean, then I think it's worthwhile.

    --
    Benoit "tsuna" Sigoure
    Software Engineer @ www.StumbleUpon.com
  • Todd Lipcon at Feb 22, 2012 at 8:29 pm ⇧

    On Wed, Feb 22, 2012 at 12:24 PM, tsuna wrote:
    On Wed, Feb 22, 2012 at 9:23 AM, Ted Yu wrote:
    Benoit's comment is directly related to our practice, especially when we
    add new methods which are only called by unit tests.
    I didn't dare to say it, but now that you do… :P

    HBase exposes a TON of implementation details in public APIs.  Makes
    things harder to refactor because you don't know if anyone out there
    is relying on this method or extending that class.
    The annotations stuff that Jimmy's working on will help a bit in terms
    of clarifying which APIs are meant for public consumption and which
    just happen to be public classes because Java's scoping sucks.
    Mocking out things that are hidden is certainly a bit harder than
    calling into a public API javadoced as "for test only", but if it
    keeps the APIs clean, then I think it's worthwhile.
    One thing we've started to do in Hadoop is to actually name methods
    "getFooForTests" or "setFooForTests" instead of just annotating them.
    This makes clear that you should never call it from non-test code, and
    relies on far less magic than PowerMock.

    Todd
    --
    Benoit "tsuna" Sigoure
    Software Engineer @ www.StumbleUpon.com


    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Ted Yu at Feb 22, 2012 at 8:34 pm ⇧
    I logged https://issues.apache.org/jira/browse/HBASE-5456

    I think we should make "for test only" methods private in the above JIRA.

    Feel free to comment on the JIRA or in this thread.

    Thanks
    On Wed, Feb 22, 2012 at 12:24 PM, tsuna wrote:
    On Wed, Feb 22, 2012 at 9:23 AM, Ted Yu wrote:
    Benoit's comment is directly related to our practice, especially when we
    add new methods which are only called by unit tests.
    I didn't dare to say it, but now that you do… :P

    HBase exposes a TON of implementation details in public APIs. Makes
    things harder to refactor because you don't know if anyone out there
    is relying on this method or extending that class.

    Mocking out things that are hidden is certainly a bit harder than
    calling into a public API javadoced as "for test only", but if it
    keeps the APIs clean, then I think it's worthwhile.

    --
    Benoit "tsuna" Sigoure
    Software Engineer @ www.StumbleUpon.com
  • Ted Dunning at Feb 22, 2012 at 9:23 pm ⇧
    Jmockit has worked well for both mocking and stubbing for me. My problem was System.currentTimeMillis and if you can patch that you can patch most anything.

    Sent from my iPhone
    On Feb 22, 2012, at 9:23 AM, Ted Yu wrote:

    Benoit's comment is directly related to our practice, especially when we
    add new methods which are only called by unit tests.

    FYI

    ---------- Forwarded message ----------
    From: tsuna <tsunanet@gmail.com>
    Date: Wed, Feb 22, 2012 at 9:13 AM
    Subject: Re: asynchbase-1.2.0-rc1 is available for download
    To: Jim Scott <jim@13ways.com>
    Cc: AsyncHBase <asynchbase@googlegroups.com>

    On Wed, Feb 22, 2012 at 8:50 AM, Jim Scott wrote:
    I ask because I am writing some unit tests to make sure that my code is
    working properly and I cannot mock the HBaseClient because it is final. I
    completely understand the rationale to make it final, but without it
    implement an interface or being non-final I cannot mock the object.
    Hi Jim,
    OpenTSDB has unit tests that are mocking out HBaseClient just fine
    [1]. You can mock out pretty much anything on the JVM: final,
    private, JDK stuff, etc. All you need is the right tools. I've been
    very happy with PowerMock. It supports Mockito and EasyMock.

    I've never been keen on mutilating public interfaces for the sake of
    testing. With tools like PowerMock, we can keep the public APIs tidy
    while mocking and overriding anything, even in the most private guts
    of the classes.

    [1]
    https://github.com/stumbleupon/opentsdb/blob/master/src/uid/TestUniqueId.java#L66

    --
    Benoit "tsuna" Sigoure
    Software Engineer @ www.StumbleUpon.com

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categorieshbase, hadoop
postedFeb 22, '12 at 5:24p
activeFeb 22, '12 at 9:26p
posts7
users5
websitehbase.apache.org

5 users in discussion

Ted Dunning: 2 posts Ted Yu: 2 posts Jesse Yates: 1 post Tsuna: 1 post Todd Lipcon: 1 post

Content

People

Support

Translate

site design / logo © 2022 Grokbase