Update instructions for running tests
Fix testsome invocation
|Deletions are marked like this.||Additions are marked like this.|
|Line 27:||Line 27:|
|Simply run `ant` to run all unit tests. To run a specific test class, run `ant -Dtest.name=<ClassName>`. To run a specific test method, run `ant -Dtestsome.name=<ClassName> -Dtestsome.methods=<comma-separated list of method names>`.||Simply run `ant` to run all unit tests. To run a specific test class, run `ant -Dtest.name=<ClassName>`. To run a specific test method, run `ant testsome -Dtest.name=<ClassName> -Dtest.methods=<comma-separated list of method names>`.|
Check if someone else has already begun work on the change you have in mind in the issue tracker
- If not, create a ticket describing the change you're proposing in the issue tracker
- Check out the latest version of the source code
git clone http://git-wip-us.apache.org/repos/asf/cassandra.git cassandra-trunk
- Modify the source to include the improvement/bugfix
Verify that you follow Cassandra's CodeStyle.
- Verify that your change works by adding a unit test.
- Make sure all tests pass by running "ant test" in the project directory.
You can run specific tests like so: ant test -Dtest.name=SSTableReaderTest`
For testing multi-node behavior, https://github.com/pcmanus/ccm is useful
- When you're happy with the result create a patch:
git add <any new or modified file>
git commit -m '<message>'
- git format-patch
mv <patch-file> <branchname-issue.txt> (e.g. trunk-123.txt, cassandra-0.6-123.txt)
- Attach the newly generated patch to the issue and click "Submit patch" in the left side of the JIRA page
- Wait for other developers or committers to review it and hopefully +1 the ticket
- Wait for a committer to commit it.
Testing and Coverage
Setting up and running system tests:
Running the Unit Tests
Simply run ant to run all unit tests. To run a specific test class, run ant -Dtest.name=<ClassName>. To run a specific test method, run ant testsome -Dtest.name=<ClassName> -Dtest.methods=<comma-separated list of method names>.
You can also run tests in parallel: ant test -Dtest.runners=4.
Running the dtests
The dtests use ccm to test a local cluster.
Install ccm. You can do this with pip by running pip install ccm.
Install nosetests. With pip, this is pip install nose.
Clone the dtest repo: https://github.com/riptano/cassandra-dtest.git
Set $CASSANDRA_DIR to the location of your cassandra checkout. For example: export CASSANDRA_DIR=/home/joe/cassandra. Make sure you've already built cassandra in this directory.
Run all tests by running nosetests from the dtest checkout. You can run a specific module like so: nosetests cql_tests.py. You can run a specific test method like this: nosetests cql_tests.py:TestCQL.counters_test
Running the code coverage task
ant codecoverage -Dcobertura.dir=/path/to/cobertura
/path/to/cobertura/cobertura-report.sh --destination build/cobertura/html source code src/java
Buildbot runs the Cassandra tests continuously: http://ci.apache.org/builders/cassandra-trunk. (Builders for stable branches also exist.)
- IntelliJ Project Settings:
Cassandra uses ivy [http://ant.apache.org/ivy/] to fetch compile-time dependencies. Ivy needs to be able to access the web servers that host the dependencies (typically maven repositories). If your internet access is proxied, ivy (ant, really) needs to know about it. There are two ways to accomplish this:
Include -Dhttp.proxyHost=myproxy -Dhttp.proxyPort=3128 in the ANT_OPTS environment variable. See the ant wiki [http://wiki.apache.org/ant/TheElementsOfAntStyle] for more information about ANT_OPTS.
Specify these values on the command line: ant clean build -Dhttp.proxyHost=myproxy -Dhttp.proxyPort=3128
Using git to manage patches during reviews: http://spyced.blogspot.com/2009/06/patch-oriented-development-made-sane.html
Uploading and applying patches from JIRA automagically: GitAndJIRA
Branch-specific Git repo
Sometimes it's necessary to create an entirely new repository instance to work on a branch (for example, if you need to work in a separate IDE configuration). This is particularly common in the long-term support of stable releases. The following recipe can be used to create a Git repository for tracking/committing to/from a single branch.
mkdir cassandra-0.7 cd cassandra-0.7 git init git remote add -f -t cassandra-0.7 -m master origin git://github.com/apache/cassandra.git git remote set-head origin cassandra-0.7 git merge origin # Git-svn setup cd .git; wget http://git.apache.org/authors.txt; cd .. git config svn.authorsfile ".git/authors.txt" git svn init --prefix=origin/ --branches=branches https://svn.apache.org/repos/asf/cassandra
Got commit access? Outstanding! Here are the conventions we follow.
Commit messages take the form of
<explanation> patch by <author>; reviewed by <committer> for CASSANDRA-<ticket>
When committing to multiple branches, start with the most-stable and merge forwards. For instance, if you had a fix to apply to 1.1, 1.2, and trunk, you would first commit to 1.1, and push changes. Then, switch to your 1.2 branch by doing
git checkout cassandra-1.2
- and run
git merge cassandra-1.1
If there are conflicts, resolve them and commit, followed by a push. Finally, switch to trunk by doing
git checkout trunk
git merge cassandra-1.2
again resolve conflicts if the exist, and commit and push.
See http://www.youtube.com/watch?v=AJ-CpGsCpM0 for an in-depth explanation of why fixes should be merged forwards from more-stable branches, rather than backported from trunk.
This workflow also makes it so git knows what commits have been made to earlier branches but not to trunk: if you forget to merge a fix immediately, the next time someone goes to merge from the branch, git will incorporate the forgotten ones too.