sqlobject.tests.dbtest module

The framework for making database tests.

class sqlobject.tests.dbtest.Dummy(**kw)[source]

Bases: object

Used for creating fake objects; a really poor ‘mock object’.

sqlobject.tests.dbtest.inserts(cls, data, schema=None)[source]

Creates a bunch of rows.

You can use it like:

inserts(Person, [{'fname': 'blah', 'lname': 'doe'}, ...])


inserts(Person, [('blah', 'doe')], schema=
        ['fname', 'lname'])

If you give a single string for the schema then it’ll split that string to get the list of column names.

sqlobject.tests.dbtest.raises(expected_exception, *args, **kwargs)[source]

Assert that a code block/function call raises expected_exception and raise a failure exception otherwise.

This helper produces a ExceptionInfo() object (see below).

If using Python 2.5 or above, you may use this function as a context manager:

>>> with raises(ZeroDivisionError):
...    1/0

Changed in version 2.10.

In the context manager form you may use the keyword argument message to specify a custom failure message:

>>> with raises(ZeroDivisionError, message="Expecting ZeroDivisionError"):
...    pass
Traceback (most recent call last):
Failed: Expecting ZeroDivisionError


When using pytest.raises as a context manager, it’s worthwhile to note that normal context manager rules apply and that the exception raised must be the final line in the scope of the context manager. Lines of code after that, within the scope of the context manager will not be executed. For example:

>>> value = 15
>>> with raises(ValueError) as exc_info:
...     if value > 10:
...         raise ValueError("value must be <= 10")
...     assert str(exc_info.value) == "value must be <= 10"  # this will not execute

Instead, the following approach must be taken (note the difference in scope):

>>> with raises(ValueError) as exc_info:
...     if value > 10:
...         raise ValueError("value must be <= 10")
>>> assert str(exc_info.value) == "value must be <= 10"

Or you can specify a callable by passing a to-be-called lambda:

>>> raises(ZeroDivisionError, lambda: 1/0)
<ExceptionInfo ...>

or you can specify an arbitrary callable with arguments:

>>> def f(x): return 1/x
>>> raises(ZeroDivisionError, f, 0)
<ExceptionInfo ...>
>>> raises(ZeroDivisionError, f, x=0)
<ExceptionInfo ...>

A third possibility is to use a string to be executed:

>>> raises(ZeroDivisionError, "f(0)")
<ExceptionInfo ...>
class _pytest._code.ExceptionInfo(tup=None, exprinfo=None)[source]

wraps sys.exc_info() objects and offers help for navigating the traceback.


return True if the exception is an instance of exc


return the exception as a string

when ‘tryshort’ resolves to True, and the exception is a _pytest._code._AssertionError, only the actual exception part of the exception representation is returned (so ‘AssertionError: ‘ is removed from the beginning)

getrepr(showlocals=False, style='long', abspath=False, tbfilter=True, funcargs=False)[source]

return str()able representation of this exception info. showlocals: show locals per traceback entry style: long|short|no|native traceback style tbfilter: hide entries (where __tracebackhide__ is true)

in case of style==native, tbfilter and showlocals is ignored.


Match the regular expression ‘regexp’ on the string representation of the exception. If it matches then True is returned (so that it is possible to write ‘assert excinfo.match()’). If it doesn’t match an AssertionError is raised.

tb = None

the exception raw traceback

traceback = None

the exception traceback (_pytest._code.Traceback instance)

type = None

the exception class

typename = None

the exception type name

value = None

the exception instance


Similar to caught exception objects in Python, explicitly clearing local references to returned ExceptionInfo objects can help the Python interpreter speed up its garbage collection.

Clearing those references breaks a reference cycle (ExceptionInfo –> caught exception –> frame stack raising the exception –> current frame stack –> local variables –> ExceptionInfo) which makes Python keep all objects referenced from that cycle (including all local variables in the current frame) alive until the next cyclic garbage collection run. See the official Python try statement documentation for more detailed information.

sqlobject.tests.dbtest.setupClass(soClasses, force=False)[source]

Makes sure the classes have a corresponding and correct table. This won’t recreate the table if it already exists. It will check that the table is properly defined (in case you change your table definition).

You can provide a single class or a list of classes; if a list then classes will be created in the order you provide, and destroyed in the opposite order. So if class A depends on class B, then do setupClass([B, A]) and B won’t be destroyed or cleared until after A is destroyed or cleared.

If force is true, then the database will be recreated no matter what.