commit 9a7040e27378077dc0874ad5b067298b5f25eaf9
author Michael Bolin <mbolin@fb.com> Wed Oct 30 14:07:06 2013 -0700
committer Michael Bolin <mbolin@fb.com> Wed Oct 30 14:11:20 2013 -0700
tree 5c820604a9a73a1acb3a620ac9b14c6d7b0ee0e3
parent 94cc16f9e45d66f6a17a091cddeec03c2765162b

Ensure that the default timeout in .buckconfig works with @RunWith.

Summary:
The custom logic that we use to support a default timeout for tests in `.buckconfig`
relies on our ability to use a `BuckBlockJUnit4ClassRunner` in place of a
`BlockJUnit4ClassRunner` when running JUnit. Unfortunately, when `@RunWith`
is present, the code path to produce a `BlockJUnit4ClassRunner` is not exercised,
which means our `BuckBlockJUnit4ClassRunner` is not inserted, which means
that our default timeout is not enforced.

This diff modifies the `AllDefaultPossibilitiesBuilder` that is used to select the factory
that is used to produce a `Runner` (which may or may not be a `BlockJUnit4ClassRunner`).
When `@RunWith` is present, we now take the `Runner` that is produced as a result of the
`@RunWith` annotation and wrap it with a `DelegateRunnerWithTimeout` that enforces our
default timeout.

It does this by taking the `RunNotifier` passed by the client and wrapping it in a
`DelegateRunNotifier`, which is passed to the original `Runner`. Our `DelegateRunNotifier`
intercepts events from the original `Runner` and passes them on based on the state of
test execution relative to the default timeout from `.buckconfig`.

Unfortunately, the logic in our `DelegateRunnerWithTimeout`/`DelegateRunNotifier` is not
as airtight as the logic in our `BuckBlockJUnit4ClassRunner`, so we are not going to delete
our `BuckBlockJUnit4ClassRunner` codepath just yet.

Test Plan: RunWithDefaultTimeoutIntegrationTest.