Table Of Contents

Previous topic

Spyne Documentation

Next topic

Spyne FAQ

This Page

Running Tests Locally

While the test coverage for Spyne is not that bad, we always accept new tests that cover new use-cases. Please consider contributing tests even if your use-case is working fine! Given the nature of open-source projects, Spyne may shift focus or change maintainers in the future. This can result in patches which may cause incompatibilities with your existing code base. The only way to detect such corner cases is to have a great test suite.

Spyne’s master repository is already integrated with Head over to to see it for yourself.

As the necessary configuration is already done, it’s very simple to integrate your own fork of Spyne with, which should come in handy even if you don’t plan to be a long-time contributor to Spyne. Just sign in with your Github account and follow instructions.

If you want to run the tests locally, just run:

python test

This call will install every possible dependency of Spyne in the current working directory, which takes care of most of the tedium of setting up a testing environment. The last thing you need to do is to make sure there is a live PostgreSQL instance, so that all of the db integration tests also work.

Spyne’s generic test script does not run WS-I tests. Also see the related section below.

If you don’t want this or just want to run a specific test, pytest is a nice tool that lets you do just that:

py.test -v --tb=short spyne/test/protocol/

You can run tests directly by executing them as well. This will use Python’s builtin unittest package which is less polished, but just fine.


Note that just running py.test or similar powerful test-juggling software naively in the root directory of tests won’t work. Spyne runs some interoperability tests by starting an actual daemon listening to a particular port and then making (or processing) real requests, so running all tests in one go is problematic. The rather specialized logic in for running tests is the result of these quirks. Patches are welcome!

SOAP Interoperability Tests

The interoperability servers require twisted.web.


Python interop tests currently use Spyne’s own clients and suds. The suds test is the first thing we check and try not to break.


You need Ruby 1.8.x to run the ruby interop test against soap_http_basic. Unfortunately, the Ruby Soap client does not do proper handling of namespaces, so you’ll need to turn off strict validation if you want to work with ruby clients.

Ruby test module is very incomplete, implementing only two (echo_string and echo_integer) tests. We’re looking for volunteers who’d like to work on increasing test coverage for other use cases.


There isn’t any .Net tests for Spyne. WS-I test compliance reportedly covers .Net use cases as well. Patches are welcome!


The WS-I test is written in Java. But unfortunately, it only focuses on Wsdl document and not the Soap functionality itself. We’re looking for volunteers who’d like to work on writing Java interop tests for spyne.

To run the Wsdl tests, you should first get wsi-interop-tools package from and unpack it next to Here are the relevant links:

See also for more info.

Now run the soap_http_basic interop test server and run If all goes well, you should get a new wsi-report-spyne.xml file in the same directory.

Here’s the directory tree from a working setup:

|-- README.rst
|-- (...)
|-- interop
|   |-- (...)
|   |--
|   `-- wsi-test-tools
|       |-- License.htm
|       |-- README.txt
|       `-- (...)
`-- (...)

Integrating with CI systems

Spyne is already integrated with Jenkins and

The travis configuration file is located in the root of the source repository, under its standard name: .travis.yml

A script for running Spyne test suite inside Jenkins can also be found in the same directory as this README file, under the name Paste it to the “executable script” section in Jenkins configuration page.