There are currently two sorts of tests, unit tests, which aim to exercise
small pieces of code such as individual functions and methods, and system tests,
which aim to test that all the pieces of the system work together as expected.

If you add a new feature to PyNN, or fix a bug, you should write both unit and
system tests.

Unit tests should where necessary make use of mock/fake/stub/dummy objects to
isolate the component under test as well as possible. The pyNN.mock
module is a complete mock simulator backend that may be used for this purpose.
Except when testing a specific simulator interface, unit tests should be able to
run without a simulator installed.

System tests should be written so that they can run with any of the simulators.
The suggested way to do this is to write test functions, in a separate file,
that take a simulator module as an argument, and then call these functions from
test_neuron.py, test_nest.py, etc.

The test/unsorted directory contains a number of old tests that are either
no longer useful or have not yet been adapted to the nose framework. These are
not part of the test suite, but we are gradually adapting those tests that are
useful and deleting the others.

The best way to get started with contributing code to PyNN is to fix a small
bug (bugs marked “minor” in the bug tracker) in your checkout of
the code. Once you are happy with your changes, run the test suite again to check
that you have not introduced any new bugs. If this is your first contribution
to the project, please add your name and affiliation/employer to AUTHORS.

To make a release of PyNN requires you to have permissions to upload PyNN
packages to the Python Package Index, and to
upload documentation to the neuralensemble.org server. If you are interested
in becoming release manager for PyNN, please contact us via the mailing list.

When you think a release is ready, run through the following checklist one
last time:

do all the tests pass? This means running nosetests in
test/unittests and test/system and running make doctest in
doc. You should do this on at least two Linux systems – one a very
recent version and one at least a year old, and on at least one version of
Mac OS X. You should also do this with Python 2.6, 2.7 and 3.4, 3.5 or 3.6.

do all the example scripts generate the correct output? Run the
run_all_examples.py script in examples/tools and then visually
check the .png files generated in examples/tools/Results. Again,
you should do this on at least two Linux systems and one Mac OS X system.

does the documentation build without errors? You should then at least skim
the generated HTML pages to check for obvious problems.

have you updated the version numbers in setup.py, pyNN/__init__.py,
doc/conf.py and doc/installation.txt?

have you updated the changelog?

Once you’ve confirmed all the above, create a source package using:

$ python setup.py sdist

and check that it installs properly (you will find it in the dist
subdirectory.

Now you should commit any changes, then tag with the release number as follows: