Since you have source code available, you may also consider running the whole
test suite of Pythoscope:

$ python setup.py test

Usage

You can use the tool through a single pythoscope command. To prepare
your project for use with Pythoscope, type:

$ pythoscope --init path/to/your/project/

It’s only doing static analysis, and doesn’t import your modules or
execute your code in any way, so you’re perfectly safe to run it on
anything you want. After that, a directory named .pythoscope will be
created in the current directory. To generate test stubs based on your
project, select files you want to generate tests for:

Test files will be saved to your test directory, if you have one, or
into a new tests/ directory otherwise. Test cases are aggregated
into TestCase classes. Currently each production class and each
production function gets its own TestCase class.

Some of the classes and functions are ignored by the generator - all
which name begins with an underscore, exception classes, and some
others.

Generator itself is configurable to some extent, see:

$ pythoscope --help

for more information on available options.

Tutorial

Let’s say you’re working on this old Python project. It’s ugly and
unpredictable, but you have no choice but to keep it alive. Luckily
you’ve heard about this new tool called Pythoscope, which can help
you cure the old guy.

You start by descending to the project directory:

$ cd wild_pythons/

and initializing Pythoscope internal structures:

$ pythoscope --init

This command creates .pythoscope/ subdirectory, which will hold all
information related to Pythoscope. You look at the poor snake:

That’s a starting point for your testing struggle, but there’s much more
Pythoscope can help you with. All you have to do is give it some more
information about your project.

Since Python is a very dynamic language it’s no surprise that most
information about the application can be gathered during runtime. But legacy
applications can be tricky and dangerous, so Pythoscope won’t run any code
at all unless you explicitly tell it to do so. You can specify which code
is safe to run through, so called, points of entry.

Point of entry is a plain Python module that executes some parts of your code.
You should keep each point of entry in a separate file in the
.pythoscope/points-of-entry/ directory. Let’s look closer at our old friend:

Pythoscope correctly captured creation of the OldPython object and call to
its hiss() method. Congratulations, you have a first working test case without
doing much work! But Pythoscope can generate more than just invdividual test
cases. It all depends on the points of entry you define. More high-level they
are, the more information Pythoscope will be able to gather, which directly
translates to the number of generated test cases.

So let’s try writing another point of entry. But first look at another module
we have in our project:

You got all of that for mere 2 additional lines of code. What’s even better
is the fact that you can safely modify and extend test cases generated by
Pythoscope. Once you write another point of entry or add new behavior to your
system you can run Pythoscope again and it will only append new test cases
to existing test modules, preserving any modifications you could have made
to them.