Other approach is to create dependency tree for tests (what tests depends on which code) and CI to run only the impacted tests for the corresponding code change (refer http://google-engtools.blogspot.in/2011/06/testing-at-speed-and-scale-of-google.html). I am not sure how dependency tree will be maintain, but if they are doing it then there must be some way.
Running multiple tests simultaneously on same machine helps to quickly certify the change. I think we do it for dunit. Thanks, Rahul On Thu, Jun 18, 2015 at 12:20 AM, Roman Shaposhnik <[email protected]> wrote: > On Tue, Jun 16, 2015 at 3:13 PM, jun aoki <[email protected]> wrote: > > Anthony, thank you for providing the info. It is straightforward while > > developing. > > > > Some of us think we should run all tests (several hours according to Dan) > > and there are good reasons to do so. > > Roman, if you know the answer, please let us know; is it OK to occupy > > jenkins slaves for several hours on each test-patch on builds.a.o? Is > there > > any guideline we should follow in order to use builds.a.o? > > Quick answer: it is ok to start doing it. Go ahead! > > Longer answer: this really is a self-throttling question. If at some point > the > rate of patch submission will exceed the Jenkins capacity you may want > to invest in reducing the time it takes for tests required for test > patch to run. > After all, the whole point of the exerisze here is to increase the > confidence > of however is reviewing the patch by looking at test-patch reports. If > waiting > for those reports takes days -- it'll stop being acceptable. > > Thanks, > Roman. >
