Changeset - f879e7ea1c4b
[Not reviewed]
default
0 1 0
Thomas De Schampheleire - 11 years ago 2015-03-17 20:53:50
thomas.de.schampheleire@gmail.com
docs/contributing: explicitly mention some useful options to nosetests
1 file changed with 7 insertions and 1 deletions:
0 comments (0 inline, 0 general)
docs/contributing.rst
Show inline comments
 
@@ -40,49 +40,55 @@ To get started with development::
 
        firefox http://127.0.0.1:5000/
 

	
 
You can also start out by forking https://bitbucket.org/conservancy/kallithea
 
on Bitbucket_ and create a local clone of your own fork.
 

	
 

	
 
Running tests
 
-------------
 

	
 
After finishing your changes make sure all tests pass cleanly. You can run
 
the testsuite running ``nosetests`` from the project root, or if you use tox
 
run ``tox`` for python2.6-2.7 with multiple database test.
 

	
 
When using `nosetests`, the `test.ini` file is used with an SQLite database. Edit
 
this file to change your testing enviroment.
 

	
 
It is possible to avoid recreating the full test database on each invocation of
 
the tests, thus eliminating the initial delay. To achieve this, run the tests as::
 

	
 
    paster serve test.ini --pid-file=test.pid --daemon
 
    KALLITHEA_WHOOSH_TEST_DISABLE=1 KALLITHEA_NO_TMP_PATH=1 nosetests
 
    kill -9 $(cat test.pid)
 

	
 
You can run individual tests by specifying their path as argument to nosetests.
 
nosetests also has many more options, see `nosetests -h`.
 
nosetests also has many more options, see `nosetests -h`. Some useful options
 
are::
 

	
 
    -x, --stop            Stop running tests after the first error or failure
 
    -s, --nocapture       Don't capture stdout (any stdout output will be
 
                          printed immediately) [NOSE_NOCAPTURE]
 
    --failed              Run the tests that failed in the last test run.
 

	
 
Coding/contribution guidelines
 
------------------------------
 

	
 
Kallithea is GPLv3 and we assume all contributions are made by the
 
committer/contributor and under GPLv3 unless explicitly stated. We do care a
 
lot about preservation of copyright and license information for existing code
 
that is brought into the project.
 

	
 
We don't have a formal coding/formatting standard. We are currently using a mix
 
of Mercurial (http://mercurial.selenic.com/wiki/CodingStyle), pep8, and
 
consistency with existing code. Run whitespacecleanup.sh to avoid stupid
 
whitespace noise in your patches.
 

	
 
We support both Python 2.6.x and 2.7.x and nothing else. For now we don't care
 
about Python 3 compatibility.
 

	
 
We try to support the most common modern web browsers. IE8 is still supported
 
to the extent it is feasible but we may stop supporting it very soon.
 

	
 
We primarily support Linux and OS X on the server side but Windows should also work.
 

	
 
Html templates should use 2 spaces for indentation ... but be pragmatic. We
 
should use templates cleverly and avoid duplication. We should use reasonable
0 comments (0 inline, 0 general)