Developers contributing code to the Longbow base code will be expected to provide unit tests for their contributions and have these passing at time of merger, pull requests with failing tests will not be accepted. It is also strongly suggested to gain as much testing coverage as possible for contributions, as poor coverage will also lead to rejected contributions.
The unit tests are run via Travis CI automatically upon commits and pull requests to assist maintainers with assessing whether code contributions represent the quality and stability our users deserve.
Developers can rely on the Travis tests if they like, but this can often mean a lot of little tweaks need commiting to GitHub branches before they are ready. It is often a better idea to implement local testing with your installed Python toolchain and then push to GitHub and have Travis do the multi-version based testing.
A convenient way to set up a simple test environment locally is to implement the following recipe.
1. Install testing tools
To start testing, you’ll need some tools, so first thing is to get these if you haven’t already.
pip install --user pytest
pip install --user mock
pip install --user coverage
beautify output (optional):
pip install --user pytest-sugar
2. Make testing script to copy source and launch test suite
Next, you will need a way to run your tests without disturbing your pristine source code. The simplest way to do this is have a simple script copy and launch your tests. To do this creare a bash script:
#!/usr/bin/env bash # copy source to user home directory cp -r /path/to/your/longbow-source ~ # change path to longbow source cd ~/Longbow # run tests and report coverage coverage run --source longbow -m py.test coverage report -m # after testing, clean up cd .. rm -rf ~/Longbow
after saving, make it executable:
chmod +x ~/.local/bin/test-longbow
that should be it. You should simply be able to run “test-longbow” and see the unit testing suite run its tests locally on your machine. This will give details of the coverage report so that you can see lines that are not covered by testing and details of any tests that fail as a result of your changes. Failing tests are not always a bad idea, you may have altered core functionality to fix a bug that is currently passing an existing test, you should then fix the existing tests to test your new code.
Thats it, happy coding…..