gjacoby126 commented on a change in pull request #3523: URL: https://github.com/apache/hbase/pull/3523#discussion_r675865887
########## File path: hbase-common/src/test/java/org/apache/hadoop/hbase/HBaseCommonTestingUtil.java ########## @@ -40,7 +40,9 @@ /** * Common helpers for testing HBase that do not depend on specific server/etc. things. */ [email protected](HBaseInterfaceAudience.PHOENIX) [email protected]({HBaseInterfaceAudience.COPROC, Review comment: I'm not sure I understand what the compromise is here? For example, I wear three different hats. I write code for HBase itself, for Phoenix, and for my dayjob. You seem to be arguing that the type of test infrastructure I require depends on what hat I'm wearing, not on the code I'm writing. I think you're saying that server-side component tests are good when I wear the HBase hat, a tolerated compromise when I wear the Phoenix hat, and bad when I wear the dayjob hat? And that that would be the case _even for the same code _ depending on where I intended to push it when it's done? In my view, HBase tests that just exercise the client API should use the TestingHBaseCluster. Same with Phoenix tests, or dayjob tests that only rely on the HBase client API. Tests that exercise server-side components that need the extra control over server-side state should be able to do so. That's true whether the components are housed in an HBase repo, or a Phoenix repo, or any other project, open source or not. HBase gives a lot of ways to create server side code, and they all need to be tested. The IA should recognize that. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
