[
https://issues.apache.org/jira/browse/HBASE-6201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13293981#comment-13293981
]
Enis Soztutar commented on HBASE-6201:
--------------------------------------
bq. Bigtop provides a framework for integration tests that is, essentially,
'mvn verify'.
Thanks for bringing this up. I know that bigtop provides a test framework for
integration tests. From my perspective, I see hbase and bigtop sharing
responsibility on the testing side, and we can work to define best practices
for this, and would love to hear Bigtop's perspective as well.
I completely agree that HBase code, should not bother with deployments, cluster
management services, smoke testing, nor integration with other components
(hive, pig, etc). Those kind of functionality can belong in BigTop or similar
projects.
However, some core testing functionality, is better managed by the HBase
project. Lets consider the TestMasterFailover test. Right now it is a unit
test, testing the internal state transitions, when the master fails. However,
we can extend this test to run from the client side, and see whether the
transition is transparent when we kill the active master on an actual cluster.
That kind of testing, should be managed by HBase itself, because, although they
would run from the client side, these kind of tests are hbase-specific, and
better managed by Hbase devs. Also, I do not expect BigTop to host a large
number of test cases for all of the stack (right now 8 projects).
Having said that, in this issue, we can come up with a way to interface with
BigTop (and other projects, custom jenkins jobs, etc) so that, these tests can
use the underlying deployment, server management, etc services, and BigTop, and
others can just execute the HBase internal integration tests on the cluster. A
simple way for this is that HBase to offer {{mvn verify}} to be consumed by
BigTop, and those tests will use HBase's own scripts (and SSH, etc) for
cluster/server management. Since BigTop configures the cluster to be usable by
those, it should be ok.
> HBase integration/system tests
> ------------------------------
>
> Key: HBASE-6201
> URL: https://issues.apache.org/jira/browse/HBASE-6201
> Project: HBase
> Issue Type: Bug
> Components: test
> Affects Versions: 0.96.0
> Reporter: Enis Soztutar
> Assignee: Enis Soztutar
>
> Integration and general system tests have been discussed previously, and the
> conclusion is that we need to unify how we do "release candidate" testing
> (HBASE-6091).
> In this issue, I would like to discuss and agree on a general plan, and open
> subtickets for execution so that we can carry out most of the tests in
> HBASE-6091 automatically.
> Initially, here is what I have in mind:
> 1. Create hbase-it (or hbase-tests) containing forward port of HBASE-4454
> (without any tests). This will allow integration test to be run with
> {code}
> mvn verify
> {code}
> 2. Add ability to run all integration/system tests on a given cluster. Smt
> like:
> {code}
> mvn verify -Dconf=/etc/hbase/conf/
> {code}
> should run the test suite on the given cluster. (Right now we can launch some
> of the tests (TestAcidGuarantees) from command line). Most of the system
> tests will be client side, and interface with the cluster through public
> APIs. We need a tool on top of MiniHBaseCluster or improve
> HBaseTestingUtility, so that tests can interface with the mini cluster or the
> actual cluster uniformly.
> 3. Port candidate unit tests to the integration tests module. Some of the
> candidates are:
> - TestAcidGuarantees / TestAtomicOperation
> - TestRegionBalancing (HBASE-6053)
> - TestFullLogReconstruction
> - TestMasterFailover
> - TestImportExport
> - TestMultiVersions / TestKeepDeletes
> - TestFromClientSide
> - TestShell and src/test/ruby
> - TestRollingRestart
> - Test**OnCluster
> - Balancer tests
> These tests should continue to be run as unit tests w/o any change in
> semantics. However, given an actual cluster, they should use that, instead of
> spinning a mini cluster.
> 4. Add more tests, especially, long running ingestion tests (goraci, BigTop's
> TestLoadAndVerify, LoadTestTool), and chaos monkey style fault tests.
> All suggestions welcome.
--
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
