[
https://issues.apache.org/jira/browse/HBASE-6201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13396272#comment-13396272
]
Roman Shaposhnik commented on HBASE-6201:
-----------------------------------------
Sorry for chiming in late, but here's how I see it after quite a bit of
internal discussions with some of the HBase and HDFS devs. First of all, lets
not got caught up in terminology of what is a unit test, what is a functional
test, etc. If we assume this stance than all the tests, essentially, fall under
the 3 main categories:
# tests that muck about with the internals of the particular single project
(HDFS, HBase, etc) using things like private APIs (or sometimes even things
like reflections, etc to really get into the guts of the system)
# tests that concern themselves with a single project (HDFS, HBase, etc) but
use only public APIs AND don't use
# tests that concern themselves with multiple projects at the same time
(imagine a test that submits an Oozie workflow that has some Pig and Hive
actions actively manipulating data in HBase) but only using public APIs
It is pretty clear that #3 definitely belongs to Bigtop while #1 definitely
belongs to individual projects. For quite some time I was thinking that #2
belongs to Bigtop testbase as well, but I've changed my mind. I now believe
that such tests should reside in individual projects and:
# be clearly marked as such not to be confused with class #1 (test suites,
test lists, naming convention work, etc)
# be written/refactored in such a way that doesn't tie them to a particular
deployment strategy. IOW they should assume the subsystem to be deployed.
# be hooked up to the project build's system in such a way that takes care of
deploying the least amount of a system to make them run (e.g. MiniDFS, MiniMR,
etc.)
Thus if HBase can follow these rules and have a subset of tests that can be
executed in different envs. both HBase core devs and bigger Bigtop dev
community win, since we can leverage each other's work.
Makes sense? If it does I can help with re-factoring.
> 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
