Repository Summary
Checkout URI | https://github.com/box/flaky.git |
VCS Type | git |
VCS Version | v3.1.0 |
Last Updated | 2016-02-11 |
Dev Status | MAINTAINED |
CI status | No Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Packages
Name | Version |
---|---|
flaky | 3.1.0 |
README
flaky
About
Flaky is a plugin for nose or py.test that automatically reruns flaky tests.
Ideally, tests reliably pass or fail, but sometimes test fixtures must rely on components that aren't 100% reliable. With flaky, instead of removing those tests or marking them to \@skip, they can be automatically retried.
For more information about flaky, see this presentation.
Marking tests flaky
To mark a test as flaky, simply import flaky and decorate the test with \@flaky:
``` {.sourceCode .python} from flaky import flaky
``` {.sourceCode .python}
@flaky
def test_something_that_usually_passes(self):
value_to_double = 21
result = get_result_from_flaky_doubler(value_to_double)
self.assertEqual(result, value_to_double * 2, 'Result doubled incorrectly.')
By default, flaky will retry a failing test once, but that behavior can be overridden by passing values to the flaky decorator. It accepts two parameters: max_runs, and min_passes; flaky will run tests up to max_runs times, until it has succeeded min_passes times. Once a test passes min_passes times, it's considered a success; once it has been run max_runs times without passing min_passes times, it's considered a failure.
``` {.sourceCode .python} @flaky(max_runs=3, min_passes=2) def test_something_that_usually_passes(self): “"”This test must pass twice, and it can be run up to three times.””” value_to_double = 21 result = get_result_from_flaky_doubler(value_to_double) self.assertEqual(result, value_to_double * 2, ‘Result doubled incorrectly.’)
### Marking a class flaky
In addition to marking a single test flaky, entire test cases can be
marked flaky:
``` {.sourceCode .python}
@flaky
class TestMultipliers(TestCase):
def test_flaky_doubler(self):
value_to_double = 21
result = get_result_from_flaky_doubler(value_to_double)
self.assertEqual(result, value_to_double * 2, 'Result doubled incorrectly.')
@flaky(max_runs=3)
def test_flaky_tripler(self):
value_to_triple = 14
result = get_result_from_flaky_tripler(value_to_triple)
self.assertEqual(result, value_to_triple * 3, 'Result tripled incorrectly.')
The \@flaky class decorator will mark test_flaky_doubler as flaky, but it won't override the 3 max_runs for test_flaky_tripler (from the decorator on that test method).
Don't rerun certain types of failures
Depending on your tests, some failures are obviously not due to flakiness. Instead of rerunning after those failures, you can specify a filter function that can tell flaky to fail the test right away.
``` {.sourceCode .python} def is_not_crash(err, *args): return not issubclass(err[0], ProductCrashedError)
@flaky def test_something(): raise ProductCrashedError
@flaky(rerun_filter=is_not_crash) def test_something_else(): raise ProductCrashedError
Flaky will run [test\_something]{.title-ref} twice, but will only run
[test\_something\_else]{.title-ref} once.
It can also be used to incur a delay between test retries:
``` {.sourceCode .python}
import time
def delay_rerun(*args):
time.sleep(1)
return True
@flaky(rerun_filter=delay_rerun)
def test_something_else():
...
Activating the plugin
Like any nose plugin, flaky can be activated via the command line:
``` {.sourceCode .console} nosetests –with-flaky
With py.test, flaky will automatically run. It can, however be disabled
via the command line:
``` {.sourceCode .console}
py.test -p no:flaky
Command line arguments
No Flaky Report
Pass --no-flaky-report
to suppress the report at the end of the run
detailing flaky test results.
Shorter Flaky Report
Pass --no-success-flaky-report
to suppress information about
successful flaky tests.
Force Flaky
Pass --force-flaky
to treat all tests as flaky.
Pass --max-runs=MAX_RUNS
and/or --min-passes=MIN_PASSES
to control
the behavior of flaky if --force-flaky
is specified. Flaky decorators
on individual tests will override these defaults.
Additional usage examples are in the code - see test/test_example.py
Installation
To install, simply:
``` {.sourceCode .console} pip install flaky
Compatibility
-------------
Flaky is tested with the following test runners and options:
- Nosetests. Doctests cannot be marked flaky.
- Py.test. Works with [pytest-xdist]{.title-ref} but not with the
[\--boxed]{.title-ref} option. Doctests cannot be marked flaky.
Contributing
------------
See
[CONTRIBUTING.rst](https://github.com/box/flaky/blob/master/CONTRIBUTING.rst).
### Setup
Create a virtual environment and install packages -
``` {.sourceCode .console}
mkvirtualenv flaky
pip install -r requirements-dev.txt
Testing
Run all tests using -
``` {.sourceCode .console} tox
```
The tox tests include code style checks via pep8 and pylint.
Copyright and License
Copyright 2015 Box, Inc. All rights reserved.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
CONTRIBUTING
Contributing
All contributions are welcome to this project.
Contributor License Agreement
Before a contribution can be merged into this project, please fill out the Contributor License Agreement (CLA) located at:
http://box.github.io/cla
To learn more about CLAs and why they are important to open source projects, please see the Wikipedia entry.
How to contribute
- File an issue - if you found a bug, want to request an enhancement, or want to implement something (bug fix or feature).
- Send a pull request - if you want to contribute code. Please be sure to file an issue first.
Pull request best practices
We want to accept your pull requests. Please follow these steps:
Step 1: File an issue
Before writing any code, please file an issue stating the problem you want to solve or the feature you want to implement. This allows us to give you feedback before you spend any time writing code. There may be a known limitation that can't be addressed, or a bug that has already been fixed in a different way. The issue allows us to communicate and figure out if it's worth your time to write a bunch of code for the project.
Step 2: Fork this repository in GitHub
This will create your own copy of our repository.
Step 3: Add the upstream source
The upstream source is the project under the Box organization on GitHub. To add an upstream source for this project, type:
``` {.sourceCode .console} git remote add upstream git@github.com:box/flaky.git
This will come in useful later.
### Step 4: Create a feature branch
Create a branch with a descriptive name, such as `add-search`.
### Step 5: Push your feature branch to your fork
As you develop code, continue to push code to your remote feature
branch. Please make sure to include the issue number you\'re addressing
in your commit message, such as:
``` {.sourceCode .console}
git commit -am "Adding search (fixes #123)"
This helps us out by allowing us to track which issue your commit relates to.
Keep a separate feature branch for each issue you want to address.
Step 6: Rebase
Before sending a pull request, rebase against upstream, such as:
``` {.sourceCode .console} git fetch upstream git rebase upstream/master
```
This will add your changes on top of what's already in upstream, minimizing merge issues.
Step 7: Run the tests
Make sure that all tests are passing before submitting a pull request.
Step 8: Send the pull request
Send the pull request from your feature branch to us. Be sure to include a description that lets us know what work you did.
Keep in mind that we like to see one issue addressed per pull request, as this helps keep our git history clean and we can more easily track down issues.
Finally, please add a note in HISTORY.rst under the Upcoming section detailing what's new in your change. These will become the release notes for the next release. In addition, feel free to add yourself to AUTHORS.rst if you aren't already listed.
Repository Summary
Checkout URI | https://github.com/box/flaky.git |
VCS Type | git |
VCS Version | v3.1.0 |
Last Updated | 2016-02-11 |
Dev Status | MAINTAINED |
CI status | No Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Packages
Name | Version |
---|---|
flaky | 3.1.0 |
README
flaky
About
Flaky is a plugin for nose or py.test that automatically reruns flaky tests.
Ideally, tests reliably pass or fail, but sometimes test fixtures must rely on components that aren't 100% reliable. With flaky, instead of removing those tests or marking them to \@skip, they can be automatically retried.
For more information about flaky, see this presentation.
Marking tests flaky
To mark a test as flaky, simply import flaky and decorate the test with \@flaky:
``` {.sourceCode .python} from flaky import flaky
``` {.sourceCode .python}
@flaky
def test_something_that_usually_passes(self):
value_to_double = 21
result = get_result_from_flaky_doubler(value_to_double)
self.assertEqual(result, value_to_double * 2, 'Result doubled incorrectly.')
By default, flaky will retry a failing test once, but that behavior can be overridden by passing values to the flaky decorator. It accepts two parameters: max_runs, and min_passes; flaky will run tests up to max_runs times, until it has succeeded min_passes times. Once a test passes min_passes times, it's considered a success; once it has been run max_runs times without passing min_passes times, it's considered a failure.
``` {.sourceCode .python} @flaky(max_runs=3, min_passes=2) def test_something_that_usually_passes(self): “"”This test must pass twice, and it can be run up to three times.””” value_to_double = 21 result = get_result_from_flaky_doubler(value_to_double) self.assertEqual(result, value_to_double * 2, ‘Result doubled incorrectly.’)
### Marking a class flaky
In addition to marking a single test flaky, entire test cases can be
marked flaky:
``` {.sourceCode .python}
@flaky
class TestMultipliers(TestCase):
def test_flaky_doubler(self):
value_to_double = 21
result = get_result_from_flaky_doubler(value_to_double)
self.assertEqual(result, value_to_double * 2, 'Result doubled incorrectly.')
@flaky(max_runs=3)
def test_flaky_tripler(self):
value_to_triple = 14
result = get_result_from_flaky_tripler(value_to_triple)
self.assertEqual(result, value_to_triple * 3, 'Result tripled incorrectly.')
The \@flaky class decorator will mark test_flaky_doubler as flaky, but it won't override the 3 max_runs for test_flaky_tripler (from the decorator on that test method).
Don't rerun certain types of failures
Depending on your tests, some failures are obviously not due to flakiness. Instead of rerunning after those failures, you can specify a filter function that can tell flaky to fail the test right away.
``` {.sourceCode .python} def is_not_crash(err, *args): return not issubclass(err[0], ProductCrashedError)
@flaky def test_something(): raise ProductCrashedError
@flaky(rerun_filter=is_not_crash) def test_something_else(): raise ProductCrashedError
Flaky will run [test\_something]{.title-ref} twice, but will only run
[test\_something\_else]{.title-ref} once.
It can also be used to incur a delay between test retries:
``` {.sourceCode .python}
import time
def delay_rerun(*args):
time.sleep(1)
return True
@flaky(rerun_filter=delay_rerun)
def test_something_else():
...
Activating the plugin
Like any nose plugin, flaky can be activated via the command line:
``` {.sourceCode .console} nosetests –with-flaky
With py.test, flaky will automatically run. It can, however be disabled
via the command line:
``` {.sourceCode .console}
py.test -p no:flaky
Command line arguments
No Flaky Report
Pass --no-flaky-report
to suppress the report at the end of the run
detailing flaky test results.
Shorter Flaky Report
Pass --no-success-flaky-report
to suppress information about
successful flaky tests.
Force Flaky
Pass --force-flaky
to treat all tests as flaky.
Pass --max-runs=MAX_RUNS
and/or --min-passes=MIN_PASSES
to control
the behavior of flaky if --force-flaky
is specified. Flaky decorators
on individual tests will override these defaults.
Additional usage examples are in the code - see test/test_example.py
Installation
To install, simply:
``` {.sourceCode .console} pip install flaky
Compatibility
-------------
Flaky is tested with the following test runners and options:
- Nosetests. Doctests cannot be marked flaky.
- Py.test. Works with [pytest-xdist]{.title-ref} but not with the
[\--boxed]{.title-ref} option. Doctests cannot be marked flaky.
Contributing
------------
See
[CONTRIBUTING.rst](https://github.com/box/flaky/blob/master/CONTRIBUTING.rst).
### Setup
Create a virtual environment and install packages -
``` {.sourceCode .console}
mkvirtualenv flaky
pip install -r requirements-dev.txt
Testing
Run all tests using -
``` {.sourceCode .console} tox
```
The tox tests include code style checks via pep8 and pylint.
Copyright and License
Copyright 2015 Box, Inc. All rights reserved.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
CONTRIBUTING
Contributing
All contributions are welcome to this project.
Contributor License Agreement
Before a contribution can be merged into this project, please fill out the Contributor License Agreement (CLA) located at:
http://box.github.io/cla
To learn more about CLAs and why they are important to open source projects, please see the Wikipedia entry.
How to contribute
- File an issue - if you found a bug, want to request an enhancement, or want to implement something (bug fix or feature).
- Send a pull request - if you want to contribute code. Please be sure to file an issue first.
Pull request best practices
We want to accept your pull requests. Please follow these steps:
Step 1: File an issue
Before writing any code, please file an issue stating the problem you want to solve or the feature you want to implement. This allows us to give you feedback before you spend any time writing code. There may be a known limitation that can't be addressed, or a bug that has already been fixed in a different way. The issue allows us to communicate and figure out if it's worth your time to write a bunch of code for the project.
Step 2: Fork this repository in GitHub
This will create your own copy of our repository.
Step 3: Add the upstream source
The upstream source is the project under the Box organization on GitHub. To add an upstream source for this project, type:
``` {.sourceCode .console} git remote add upstream git@github.com:box/flaky.git
This will come in useful later.
### Step 4: Create a feature branch
Create a branch with a descriptive name, such as `add-search`.
### Step 5: Push your feature branch to your fork
As you develop code, continue to push code to your remote feature
branch. Please make sure to include the issue number you\'re addressing
in your commit message, such as:
``` {.sourceCode .console}
git commit -am "Adding search (fixes #123)"
This helps us out by allowing us to track which issue your commit relates to.
Keep a separate feature branch for each issue you want to address.
Step 6: Rebase
Before sending a pull request, rebase against upstream, such as:
``` {.sourceCode .console} git fetch upstream git rebase upstream/master
```
This will add your changes on top of what's already in upstream, minimizing merge issues.
Step 7: Run the tests
Make sure that all tests are passing before submitting a pull request.
Step 8: Send the pull request
Send the pull request from your feature branch to us. Be sure to include a description that lets us know what work you did.
Keep in mind that we like to see one issue addressed per pull request, as this helps keep our git history clean and we can more easily track down issues.
Finally, please add a note in HISTORY.rst under the Upcoming section detailing what's new in your change. These will become the release notes for the next release. In addition, feel free to add yourself to AUTHORS.rst if you aren't already listed.