logic-wise looks good to me. now that we've moved back to pytest as the default runner, i'd love to apply my coverage merging change to pantsbuild. it also has a parallel test runner, which serializes chroot building but parallelizes test runs. now that BUILD parsing is thread-safe, we can probably parallelize the chroot building part too.
our style guide prohibits trailing \. instead we prefer ()s, e.g. fail_hard = ('PANTS_PYTHON'... and 'PANTS_PY_COVERAGE' not in os.environ)
A fast mode for python tests.
Review Request #405 — Created May 23, 2014 and submitted
This mode runs all tests in a single chroot and a single python interpreter, instead of building a new chroot and spawning a new interpreter for every test target. Benefits: 1) The pants tests run in 12 seconds instead of 160 seconds. 2) Test isolation can actually hide problems sometimes. Drawbacks: Individual chroots are better for verifying that a test target's dependencies are self-contained, i.e., that they reflect all the actual deps. When running multiple tests in a single chroot, test B could provide a dep that test A relies on but doesn't declare, thus hiding a missing dep problem. This drawback is minor - it only verifies that the test target's deps are good, not the deps of the target being tested. If this works out we can consider making --fast the default in the future. The equivalent functionality is already all we do for jvm tests: we throw all our tests at JUnit in one pass. Note that this change relies on https://rbcommons.com/s/twitter/r/403/ and will ultimately be merged with it before pushing. Note also that this change gets rid of some crufty features of python_tests, namely the ability to specify entry_point, soft_dependencies and timeouts in BUILD files.
[On the merged changes] Ran all pants unittests in regular and fast mode.