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'}, ...])
Or:
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.Parameters: - message – if specified, provides a custom failure message if the exception is not raised
- match – if specified, asserts that the exception matches a text or regex
This helper produces a
ExceptionInfo()
object (see below).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
Note
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 exc_info.type == ValueError # 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 exc_info.type == ValueError
Since version
3.1
you can use the keyword argumentmatch
to assert that the exception matches a text or regex:>>> with raises(ValueError, match='must be 0 or None'): ... raise ValueError("value must be 0 or None") >>> with raises(ValueError, match=r'must be \d+$'): ... raise ValueError("value must be 42")
Legacy forms
The forms below are fully supported but are discouraged for new code because the context manager form is regarded as more readable and less error-prone.
It is possible to 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 ...>
It is also possible to pass a string to be evaluated at runtime:
>>> raises(ZeroDivisionError, "f(0)") <ExceptionInfo ...>
The string will be evaluated using the same
locals()
andglobals()
at the moment of theraises
call.Consult the API of
excinfo
objects:ExceptionInfo
.Note
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 Pythontry
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.