Testing, Debugging & Profiling
Clone this wiki locally
Several buildbots are running to ensure the functionality of ObsPy. For current reports, see http://tests.obspy.org.
All tests in ObsPy are located in the tests directory of the certain module. The
__init__.py of the tests directory itself as well as every test has a function called suite. During installation with
python setup.py ...) the
obspy-runtests script will be registered automatically.
To run all tests or a single test from the shell/cmd do one of the following:
obspy-runtests # Run all tests obspy-runtests -r -v # Run all tests in verbose mode an post output to tests.obspy.org python -m 'obspy.core.scripts.runtests.__init__' # Run all tests obspy-runtests -v obspy.core.tests.test_stream.StreamTestCase.test_adding python obspy/core/tests/test_stats.py -v python obspy/core/tests/test_stats.py -v StatsTestCase.test_pickleStats python __init__.py -v test_mseed_util.MSEEDUtilTestCase.test_unpackSteim2
To run all tests or a single test inside python do one of the following:
import obspy.core obspy.core.scripts.runtests.main() from unittest import TextTestRunner from obspy.core.tests import suite TextTestRunner().run(suite()) # Run all tests TextTestRunner(verbosity=2).run(suite()) # Verbose output from unittest import TextTestRunner from obspy.core.tests.test_stats import suite TextTestRunner().run(suite()) # Run all tests TextTestRunner(verbosity=2).run(suite()) # Verbose output
Running the test verbose exposes the available tests.
Debugging in Python is best with pdb. In the interesting place of your Python source code set the debugger by
import pdb; pdb.set_trace()
Running your program will now bring you to a
pdb prompt. Type
help or see http://docs.python.org/library/pdb.html for available
From IPython 0.11 (http://ipython.org) you can alternatively use the more interactive
from IPython.core.debugger import Tracer; Tracer()()
Debugging C Extensions with ddd
In order to debug C extensions ddd can be used. Possibly its also good to activate the
MALLOC_CHECK_ environment variable before hand such the memory leaks are handled in a better way (Read more ...). E.g. for debugging libmseed you need to the following.
- Compile the C extension with the debug option
- Change in the directory where all the C source files are
- Do do the following:
export MALLOC_CHECK_=2 ddd python
Run your test in the following
(gdb) prompt by (from source directory):
run ../../../tests/test_libmseed.py LibMSEEDTestCase.test_readAndWriteTrace
Debugging C Extensions with gdb
ddd is a graphical frontend for gdb. In order to debug via the network (e.g. ssh) it might be better to use gdb directly. gdb is used in the identical way like ddd in the example above.
There is also the way to debug explicitly written Python commands by gdb. Here is an example (Read more ...)
$ gdb python (gdb) run -c "import scipy; scipy.test(10,10)"
Debugging Memory Leaks with Valgrind
valgrind --tool=memcheck \ --leak-check=yes \ --suppressions=/usr/lib/valgrind/python.supp \ python mseed/tests/test_libmseed.py
Memory leaks do only show up in the ''definitely lost'' section if there is no reference to the Python object any more. Therefor explicitly delete objects in the tests --- the garbage collector seems to delete the object too late.
For profiling C-Extensions, valgrind in combination with kcachgrind can be used. For running it, do e.g.:
valgrind --tool=callgrind python tests/test_invsim.py InvSimTestCase.test_evalrespVsObsPy kcachegrind