We plan to move to Python 3 in the near future. Where possible, new code should be Python 3-compatible. In particular:
%for formatting strings.
/on numbers in a Python 3-compatible way. In particular, if you want floor division (which is the behavior of
/in Python 2), use
//instead. If you want the result of integer division to be a
1 / 2 == 0.5), add
from __future__ import divisionto the top of the imports and use
/. For more information, see the official Python 3 porting docs.
unicode_literalsin new test files.
Contributions will be evaluated by PEP8. We now strictly enforce compliance, via a linter run with Travis CI against all new pull requests. We do not enforce the default limits on line length, but have established a maximum length of 200 chars as a sanity check. You can conform to PEP8 by running
autopep8 which can be installed via
pip install autopep8 && autopep8 --in-place -a --ignore E501
Another way to make sure that your code will pass compliance checks is to run flake8 from a commit hook:
flake8 --install-hook git config flake8.strict true git config flake8.ignore E501,F811,F812,F821,F822,F823,F831,F841,N8,C9
We do not enforce import sorting, but if you choose to organize imports by some convention, use the
isort tool (
pip install isort).
session, and not
cursor when naming your connection variables, to match the style preferred by the DataStax Python Driver, which is how these tests connect to C*.
All version objects being passed from CCM are now LooseVersion objects, instead of strings. Those can still be safely compared to strings, so there is no need to do
version < LooseVersion('3.10').
Please view the following list of tags, as well as an example test. While this full list of tags is available for use, there is no need to use every tag for a given test. The description and jira_ticket fields should be included, but most others should only be used when appropriate. The test plan will live in a comment block below the test method declaration.
|Test name||Name of the test|
|Description||Brief description of the test|
|@param||Description of Parameter 1 (Usually used for helper methods)|
|@return||Description of expected return value (Usually used for helper methods)|
|@expected_errors||What exceptions this test is expected to throw on normal behavior (should be caught and expected in the test)|
|@throws||What exceptions this test would throw upon failure (if expecting a specific regression)|
|@jira_ticket||Associated JIRA ticket identifier, including the project name (e.g. |
|@expected_result||Brief summary of what the expected results of this test are|
|@test_assumptions||Test requirements (auth, hints disabled , etc)|
|@note||(future improvments, todo, etc)|
|@test_category||What categories this test falls under (deprecated)|
def test_example(self): """ Demonstrates the expected syntax for a test plan. @jira_ticket CASSANDRA-0000 @note Test should not be implemented, it is an example. """ pass
In some cases, we organize our test files by putting them in directories. If you do so, please export a module from that directory by placing an
__init__.py file in the directory with the test files. This makes the modules visible to our test infrastructure scripts that divide tests into buckets for CI.
Any and all byteman (.btm) files should be saved in the cassandra-dtest/byteman/ directory.
@sinceto skip older versions?
%for format strings?