Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Marks slow, flaky, and failing tests #1336

Merged
merged 9 commits into from
Apr 3, 2017
Merged

Conversation

pwolfram
Copy link
Contributor

Closes #1309

@pwolfram
Copy link
Contributor Author

@shoyer, this PR should also fix the issue with travis CI failing due to testing of too many open files. Note, when a user runs py.test locally, the slow tests will run. They can be skipped via running py.test --skip-slow.

@pwolfram
Copy link
Contributor Author

cc @MaximilianR

@pwolfram
Copy link
Contributor Author

pwolfram commented Mar 28, 2017

@shoyer et al, please feel free to mark additional tests as slow in this PR. I only marked the ones from #1198 that were too slow for this round.

@pwolfram
Copy link
Contributor Author

@shoyer, all tests pass and I've spot checked that this works as expected, e.g.,

xarray/tests/test_backends.py::OpenMFDatasetManyFilesTest::test_1_autoclose_netcdf4 PASSED

xarray/tests/test_backends.py::OpenMFDatasetManyFilesTest::test_1_open_large_num_files_netcdf4 SKIPPED

xarray/tests/test_backends.py::OpenMFDatasetManyFilesTest::test_2_autoclose_scipy PASSED

xarray/tests/test_backends.py::OpenMFDatasetManyFilesTest::test_2_open_large_num_files_scipy SKIPPED

xarray/tests/test_backends.py::OpenMFDatasetManyFilesTest::test_3_autoclose_pynio PASSED

xarray/tests/test_backends.py::OpenMFDatasetManyFilesTest::test_3_open_large_num_files_pynio SKIPPED

@pwolfram
Copy link
Contributor Author

@shoyer, is there anything else you would like done on this before merging?

@shoyer
Copy link
Member

shoyer commented Mar 29, 2017

@pwolfram Thanks for putting this together.

"Slow" tests on Travis aren't a huge problem -- it takes at least a minute for Travis to complete even in the best case scenario, so having to wait a minute more is not so bad. It's really an issue for interactive, local development, where it's really valuable for tests to complete in less than 10 seconds.

Flaky tests, which fail sometimes, are the problem. So think we want a different category for these many file tests, maybe "Flaky". Ideally we would have an another Travis-CI job setup to run these that isn't required to always pass, like our existing jobs for testing development versions of other libraries.

@pwolfram pwolfram changed the title Marks slow tests Marks slow and flakey tests Mar 30, 2017
@pwolfram
Copy link
Contributor Author

@shoyer, as we discussed, here is a robustness-ing of the testing as needed for 0.9.2

@pwolfram
Copy link
Contributor Author

This also fixes the issue noted in #1038 where flakey tests cause travis CI failure.

conftest.py Outdated

def pytest_addoption(parser):
parser.addoption("--skip-flakey", action="store_true",
help="skips flakey tests")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: please intent even with ( on the previous line.

.travis.yml Outdated
@@ -76,7 +76,7 @@ install:
- python setup.py install

script:
- py.test xarray --cov=xarray --cov-report term-missing --verbose
- py.test xarray --cov=xarray --cov-report term-missing --verbose --skip-flakey
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you make --skip-flakey an environment variable so we can make one of our "allowed failure" matrix builds not skip flakey tests?


slow = pytest.mark.skipif(
not pytest.config.getoption("--run-slow"),
reason="set --run-slow option to run slow tests"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to be clear, it looks like the current default behavior is:

  • Don't skip flakey tests
  • Skip slow tests

I think we actually want to flip these. Consider someone running our test suite for the first time. They probably want to understand if their xarray installation worked. It's not a big deal if this is a little slow, because they probably aren't doing this many times in a row, but not testing part of the test suite would be unfortunate. Once they notice the tests are slow, they will probably quickly look for a --skip-slow option.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've set the three categories:

  • slow (runs on default): slow
  • CI specific (runs on default, specified to be optional for CI): optionalci
  • flakey (not run on default): flakey

I don't currently have flakey tests. Plotting routines are marked as slow and long tests from the too many open files issue are marked optionalci. We have some test (h5netcdf) that are flakey because of that bug I've found. They are no longer commented but are flagged via @flakey.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The h5netcdf many file tests are not flaky: they always fail. So let's mark as a "expected failure" with pytest.mark.xfail instead.

I would argue that the "CI specific" tests should actually be considered flaky: if they fail on our CI, they are likely to also fail for users and redistributors as well (e.g., consider someone packaging xarray for conda-forge or ubuntu). Since these failures do not indicate a failed installation, we shouldn't run them by default.

I'll push a commit shortly with these changes...

@pwolfram pwolfram force-pushed the mark_slow_tests branch 6 times, most recently from 8edff08 to 58878db Compare March 31, 2017 02:38
@pwolfram pwolfram changed the title Marks slow and flakey tests Marks slow, flakey, and optional-CI tests Mar 31, 2017
@pwolfram pwolfram force-pushed the mark_slow_tests branch 6 times, most recently from d8ceca9 to 28d825f Compare March 31, 2017 02:52
.travis.yml Outdated
@@ -76,7 +158,7 @@ install:
- python setup.py install

script:
- py.test xarray --cov=xarray --cov-report term-missing --verbose
- py.test xarray --cov=xarray --cov-report term-missing --verbose $SKIP_CI $RUN_FLAKEY
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's use a single $EXTRA_FLAGS env variable

.travis.yml Outdated
@@ -13,28 +13,63 @@ matrix:
- python: 2.7
env: CONDA_ENV=py27-min
- python: 2.7
env: CONDA_ENV=py27-min SKIP_CI=--skip-optional-ci
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have a limited number of concurrent builds on Travis-CI: only five. So extra optional builds clog up other CI infrastructure and make it slower to run new tests. So I'd strongly prefer to only have one extra build optional if possible. The 15 or so you add here is too much :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shoyer-- This is the intent of my new changes: We really only need to test the h5netcdf tests that are now marked as flakey. I added this extra tests and make the rest of the tests to skip optional CI if they aren't marked as allowed failures.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, we can just run flakey tests for all tests allowed to fail and skip optional CI for all tests that must pass. This avoids having new tests and should be more economical.

@pwolfram pwolfram force-pushed the mark_slow_tests branch 3 times, most recently from 6af7c22 to b4e2a76 Compare April 2, 2017 14:00
Tests are marked using the following py.test options:

 * @slow which is run on default, not run if `--skip-slow`.
 * @optionalci is run on default, not run if `--skip-optional-ci`
 * @flakey which is not run on default, run if `--run-flakey`

Note, the `optionalci` category is needed in order to mark
tests that are environment dependent when run on continuous
integration (CI) hardware, e.g., tests that fail due to
variable loads on travis CI.
@pwolfram
Copy link
Contributor Author

pwolfram commented Apr 2, 2017

@shoyer, changes have been made as requested. Thanks!

@pwolfram
Copy link
Contributor Author

pwolfram commented Apr 2, 2017

@shoyer, all checks pass and this is ready for a review / merge when you have time.

@pwolfram pwolfram changed the title Marks slow, flakey, and optional-CI tests Marks slow, flaky, and failing tests Apr 3, 2017
```
WindowsError: [Error 32] The process cannot access the file because it
is being used by another process
```
@shoyer shoyer merged commit 685ba06 into pydata:master Apr 3, 2017
@shoyer
Copy link
Member

shoyer commented Apr 3, 2017

Thanks @pwolfram!

@QuLogic
Copy link
Contributor

QuLogic commented Apr 7, 2017

If slow tests are being run by default, I'm not sure they really need their own special option. You can mark them (with @pytest.mark.slow) and use pytest's builtin selectors to not run them: pytest -m "not slow".

Are flaky tests actually flaky or do they just not work? If flaky, and a re-run will help, then maybe try the pytest-rerunfailures plugin.

@shoyer
Copy link
Member

shoyer commented Apr 7, 2017

If slow tests are being run by default, I'm not sure they really need their own special option. You can mark them (with @pytest.mark.slow) and use pytest's builtin selectors to not run them: pytest -m "not slow".

Yes, this is a good idea.

Are flaky tests actually flaky or do they just not work? If flaky, and a re-run will help, then maybe try the pytest-rerunfailures plugin.

Thanks for pointing this out! I'm not entirely sure pytest-rerunfailures is a fit here but it's a good option to know about.

The tests are flaky on Travis-CI, but they are reliable when run locally, and we still want to keep them around as integration tests. These are slow tests that open and close quite a lot of files (2000 each).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants