On top of letting unit test suite pass, running IntegrationTestBigLinkedList (and integration test related to the feature you modify) regularly is a good practice such that the changes do not introduce regression.
FYI On Mon, Mar 14, 2016 at 2:15 PM, Bryan Beaudreault <bbeaudrea...@hubspot.com > wrote: > Hello, > > We've been using CDH community for a few years now, but have reached the > point where we want to be able to do some development and backporting > upstream. We'd like to keep the base CDH packaging for consistency, but > have come up with some automation around building CDH from source RPM, with > our patches applied. > > I realize this starts to get into the territory of self-support, and we're > ready for that in the areas we plan to work (mostly around > reporting/monitoring, for now). But I'd like to know if anyone has any best > practices for testing that your build of HBase is up to snuff? > > Are the built in unit tests enough? Do you run YCSB? PerformanceEval? > Something else? > > While we will of course be careful with testing and stressing our own > changes, I'm also just wanting to make sure that the we are hitting all the > right places to catch artifacts from the build process or missed upstream > issues. > > Thanks! >
