[jira] [Commented] (HBASE-5456) Introduce PowerMock into our unit tests to reduce unnecessary method exposure
[ https://issues.apache.org/jira/browse/HBASE-5456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13455151#comment-13455151 ] Jesse Yates commented on HBASE-5456: Reviving this discussion after talking at recent pow-wow. In short, powermock has some _interesting_ features -making it very powerful - that will really help to cleanup the codebase. For instance, it can help get rid of are the test visible methods. Yes, on one hand you could subclass the class you are testing to get at the protected methods, but then you have the issue of making that class loadable as well. It can easily spiral out of control where everything is dynamically loadable, just so you can check the state of one variable. Also, this can lead to inadvertent race conditions for timing related things, where the test-exposed method could be really simple. Also, it helps you get real objects into a state that is more easily testable. Rather than rejiggering everything through a high-level interface, you can specify things succinctly and more easily when you can introspect the object. Another great use is for managing timing issues. A lot of times to test timing of things we rely on sleeps or adding latches. The former is really brittle and the latter makes the code incredibly more complicated than it needs to be, just for testing. Problems with powermock: * complicated - yeah, it can be a bit funky, but you get used to it. * brittle - its doing reflection so there are a lot of string method/object names used. That's the problem with introspection of objects and the price we pay for cleaner running code. Tests break when you change stuff though, so you know if something goes arwy. Stack raised a possible concern that he couldn't get powermock working on the current codebase. However, I volunteered to spend the time to figure that out (at least initially) and don't think it will be all that bad. Thoughts? If people are +1, I'll work on a simple patch that adds powermock to the pom and makes a change to a test to use it. Introduce PowerMock into our unit tests to reduce unnecessary method exposure - Key: HBASE-5456 URL: https://issues.apache.org/jira/browse/HBASE-5456 Project: HBase Issue Type: Task Reporter: Ted Yu We should introduce PowerMock into our unit tests so that we don't have to expose methods intended to be used by unit tests. Here was Benoit's reply to a user of asynchbase about testability: 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 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5456) Introduce PowerMock into our unit tests to reduce unnecessary method exposure
[ https://issues.apache.org/jira/browse/HBASE-5456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13213990#comment-13213990 ] Mikhail Bautin commented on HBASE-5456: --- I think this only makes sense for HBase if people start running all unit tests for every patch (not just small and medium tests). These advanced reflection features convert some frequent types of errors from compile-time to test-time. Also, a lot of IDE search and refactoring features will be broken. Introduce PowerMock into our unit tests to reduce unnecessary method exposure - Key: HBASE-5456 URL: https://issues.apache.org/jira/browse/HBASE-5456 Project: HBase Issue Type: Task Reporter: Zhihong Yu We should introduce PowerMock into our unit tests so that we don't have to expose methods intended to be used by unit tests. Here was Benoit's reply to a user of asynchbase about testability: 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 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5456) Introduce PowerMock into our unit tests to reduce unnecessary method exposure
[
https://issues.apache.org/jira/browse/HBASE-5456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214006#comment-13214006
]
Zhihong Yu commented on HBASE-5456:
---
My understanding is that Hadoop QA does run all tests.
From https://builds.apache.org/job/PreCommit-HBASE-Build/1013/console:
{code}
Tests run: 885, Failures: 6, Errors: 1, Skipped: 10
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 37:16.809s
{code}
From
https://builds.apache.org/view/G-L/view/HBase/job/HBase-TRUNK/2665/console:
{code}
Tests run: 885, Failures: 0, Errors: 3, Skipped: 10
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 48:14.023s
{code}
Introduce PowerMock into our unit tests to reduce unnecessary method exposure
-
Key: HBASE-5456
URL: https://issues.apache.org/jira/browse/HBASE-5456
Project: HBase
Issue Type: Task
Reporter: Zhihong Yu
We should introduce PowerMock into our unit tests so that we don't have to
expose methods intended to be used by unit tests.
Here was Benoit's reply to a user of asynchbase about testability:
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
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5456) Introduce PowerMock into our unit tests to reduce unnecessary method exposure
[ https://issues.apache.org/jira/browse/HBASE-5456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214013#comment-13214013 ] Zhihong Yu commented on HBASE-5456: --- From Ted Dunning: 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. Introduce PowerMock into our unit tests to reduce unnecessary method exposure - Key: HBASE-5456 URL: https://issues.apache.org/jira/browse/HBASE-5456 Project: HBase Issue Type: Task Reporter: Zhihong Yu We should introduce PowerMock into our unit tests so that we don't have to expose methods intended to be used by unit tests. Here was Benoit's reply to a user of asynchbase about testability: 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 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5456) Introduce PowerMock into our unit tests to reduce unnecessary method exposure
[ https://issues.apache.org/jira/browse/HBASE-5456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214029#comment-13214029 ] Todd Lipcon commented on HBASE-5456: I tend to agree with Mikhail. The presence of a protected method named getRegionServerServicesForTests or something lets me know, when I'm working on the code, that this method is used, and I can easily use eclipse to tell me which unit tests use it. PowerMock and other tools which use strings to refer to functions aren't going to play nice with that, so it's easy to be unaware of test dependencies. I think these tools are best used sparingly and only to mock out system dependencies (like new FileInputStream(), InetSocketAddress.getHostName(), or System.currentTimeMillis()) Introduce PowerMock into our unit tests to reduce unnecessary method exposure - Key: HBASE-5456 URL: https://issues.apache.org/jira/browse/HBASE-5456 Project: HBase Issue Type: Task Reporter: Zhihong Yu We should introduce PowerMock into our unit tests so that we don't have to expose methods intended to be used by unit tests. Here was Benoit's reply to a user of asynchbase about testability: 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 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5456) Introduce PowerMock into our unit tests to reduce unnecessary method exposure
[
https://issues.apache.org/jira/browse/HBASE-5456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214039#comment-13214039
]
Zhihong Yu commented on HBASE-5456:
---
If the following methods can be made protected or package private, that would
be some progress:
{code}
public MapDataBlockEncoding, Integer getEncodingCountsForTest() {
src/main/java/org/apache/hadoop/hbase/io/hfile/LruBlockCache.java
public static SchemaMetrics getUnknownInstanceForTest() {
src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java
public void compactRecentForTesting(int N) throws IOException {
src/main/java/org/apache/hadoop/hbase/regionserver/Store.java
public static User createUserForTesting(Configuration conf,
public static User createUserForTesting(Configuration conf,
public static User createUserForTesting(Configuration conf,
src/main/java/org/apache/hadoop/hbase/security/User.java
public long getNumQueriesForTesting(int chunk) {
public long getNumPositivesForTesting(int chunk) {
src/main/java/org/apache/hadoop/hbase/util/CompoundBloomFilter.java
{code}
Introduce PowerMock into our unit tests to reduce unnecessary method exposure
-
Key: HBASE-5456
URL: https://issues.apache.org/jira/browse/HBASE-5456
Project: HBase
Issue Type: Task
Reporter: Zhihong Yu
We should introduce PowerMock into our unit tests so that we don't have to
expose methods intended to be used by unit tests.
Here was Benoit's reply to a user of asynchbase about testability:
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
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5456) Introduce PowerMock into our unit tests to reduce unnecessary method exposure
[ https://issues.apache.org/jira/browse/HBASE-5456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214119#comment-13214119 ] stack commented on HBASE-5456: -- I don't think that this is the kind of thing you can do by fiat. My take is that we'll use PowerMock when it makes sense (apart from the fact that PowerMock isn't exactly a walk-in-the-park). My current take on testing in hbase is that so much of our code base is test inscrutable and that anything we can do to shine light on these untested savannas of code is good by me, even unto adding public methods that allow injection of alternate classes. Introduce PowerMock into our unit tests to reduce unnecessary method exposure - Key: HBASE-5456 URL: https://issues.apache.org/jira/browse/HBASE-5456 Project: HBase Issue Type: Task Reporter: Zhihong Yu We should introduce PowerMock into our unit tests so that we don't have to expose methods intended to be used by unit tests. Here was Benoit's reply to a user of asynchbase about testability: 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 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5456) Introduce PowerMock into our unit tests to reduce unnecessary method exposure
[ https://issues.apache.org/jira/browse/HBASE-5456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214128#comment-13214128 ] Mikhail Bautin commented on HBASE-5456: --- I think most of our access restriction problems occur when the test and the class being accessed are in different packages. An alternative way to restrict test-only method access while avoiding using reflection is to define the test-only method as protected and create a subclass in the test. Introduce PowerMock into our unit tests to reduce unnecessary method exposure - Key: HBASE-5456 URL: https://issues.apache.org/jira/browse/HBASE-5456 Project: HBase Issue Type: Task Reporter: Zhihong Yu We should introduce PowerMock into our unit tests so that we don't have to expose methods intended to be used by unit tests. Here was Benoit's reply to a user of asynchbase about testability: 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 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5456) Introduce PowerMock into our unit tests to reduce unnecessary method exposure
[ https://issues.apache.org/jira/browse/HBASE-5456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214131#comment-13214131 ] Zhihong Yu commented on HBASE-5456: --- bq. to define the test-only method as protected and create a subclass in the test. +1 to above suggestion. Introduce PowerMock into our unit tests to reduce unnecessary method exposure - Key: HBASE-5456 URL: https://issues.apache.org/jira/browse/HBASE-5456 Project: HBase Issue Type: Task Reporter: Zhihong Yu We should introduce PowerMock into our unit tests so that we don't have to expose methods intended to be used by unit tests. Here was Benoit's reply to a user of asynchbase about testability: 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 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5456) Introduce PowerMock into our unit tests to reduce unnecessary method exposure
[ https://issues.apache.org/jira/browse/HBASE-5456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214140#comment-13214140 ] Jesse Yates commented on HBASE-5456: I don't see it as that big of a deal that power mock breaks the ide refactorings vs the gain of having truly cleaner code bases. Instead of having these protected test-only methods, you don't need to have any methods at all (also, why have them protected when you can just make them package private and just have tests in the same package? And should you really be testing across packages if this doesn't work? Probably not). Yeah, it can be a pain that the ide doesn't automagically take care of this stuff for you, but you should know which tests you are changing and if those elements are in fact correctly changed. On the small scale (per patch), you probably aren't going to be changing more than a handful of broken methods (if that). bq. My take is that we'll use PowerMock when it makes sense Which is how it should be used - we just need to be diligent to make sure that we really need to dig into the internals of a class rather than test around the public interfaces. Granted, we do have a lot of stuff that isn't amiable to DI, but powermock can help a lot with that too (catching constructor calls,etc) without having to rewrite massive amounts of code. bq. PowerMock isn't exactly a walk-in-the-park It's got some interesting features but the docs are actually pretty comprehensive. It just takes a little getting used to :) Introduce PowerMock into our unit tests to reduce unnecessary method exposure - Key: HBASE-5456 URL: https://issues.apache.org/jira/browse/HBASE-5456 Project: HBase Issue Type: Task Reporter: Zhihong Yu We should introduce PowerMock into our unit tests so that we don't have to expose methods intended to be used by unit tests. Here was Benoit's reply to a user of asynchbase about testability: 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 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5456) Introduce PowerMock into our unit tests to reduce unnecessary method exposure
[ https://issues.apache.org/jira/browse/HBASE-5456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214156#comment-13214156 ] Zhihong Yu commented on HBASE-5456: --- From Jim on asynchbase mailing list: Works like a champ! Thanks a ton for telling me this... I had never realized that PowerMock extended the other mocking frameworks to offer the extended functionality such as Mocking Static, Final, Private, Constructor, and Partial ... This makes things a lot easier to test. Introduce PowerMock into our unit tests to reduce unnecessary method exposure - Key: HBASE-5456 URL: https://issues.apache.org/jira/browse/HBASE-5456 Project: HBase Issue Type: Task Reporter: Zhihong Yu We should introduce PowerMock into our unit tests so that we don't have to expose methods intended to be used by unit tests. Here was Benoit's reply to a user of asynchbase about testability: 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 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5456) Introduce PowerMock into our unit tests to reduce unnecessary method exposure
[ https://issues.apache.org/jira/browse/HBASE-5456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214289#comment-13214289 ] Mikhail Bautin commented on HBASE-5456: --- On PowerMock: yes, I agree that in some cases it is a cleaner solution than creating test-only methods. @Ted: I see 1406 tests in my full test suite run. Do you have some reasons to believe that the total number of small/medium/large tests should be 885? Introduce PowerMock into our unit tests to reduce unnecessary method exposure - Key: HBASE-5456 URL: https://issues.apache.org/jira/browse/HBASE-5456 Project: HBase Issue Type: Task Reporter: Zhihong Yu We should introduce PowerMock into our unit tests so that we don't have to expose methods intended to be used by unit tests. Here was Benoit's reply to a user of asynchbase about testability: 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 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5456) Introduce PowerMock into our unit tests to reduce unnecessary method exposure
[
https://issues.apache.org/jira/browse/HBASE-5456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214300#comment-13214300
]
Zhihong Yu commented on HBASE-5456:
---
@Mikhail:
Thanks for the reminder and pardon my math :-)
{code}
Looking at https://builds.apache.org/job/PreCommit-HBASE-Build/1013/console
again, we can see:
Results :
Tests run: 519, Failures: 0, Errors: 0, Skipped: 0
...
Results :
Failed tests: testMROnTable(org.apache.hadoop.hbase.mapreduce.TestImportTsv)
testMROnTableWithCustomMapper(org.apache.hadoop.hbase.mapreduce.TestImportTsv)
testMRIncrementalLoad(org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat)
testMRIncrementalLoadWithSplit(org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat)
testExcludeMinorCompaction(org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat)
queueFailover(org.apache.hadoop.hbase.replication.TestReplication): Waited
too much time for queueFailover replication
Tests in error:
testMultiRegionTable(org.apache.hadoop.hbase.mapred.TestTableMapReduce): Job
failed!
Tests run: 885, Failures: 6, Errors: 1, Skipped: 10
{code}
519+885 is 1404 which is very close to what you have seen.
Introduce PowerMock into our unit tests to reduce unnecessary method exposure
-
Key: HBASE-5456
URL: https://issues.apache.org/jira/browse/HBASE-5456
Project: HBase
Issue Type: Task
Reporter: Zhihong Yu
We should introduce PowerMock into our unit tests so that we don't have to
expose methods intended to be used by unit tests.
Here was Benoit's reply to a user of asynchbase about testability:
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
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
