In our last lesson, we learned how to make assertions about object flow. Keep reading and we'll discuss how to make svnmock simulate the most twisted error conditions you can think of.

One of the trickiest parts of software testing is ensuring that the program can handle the rough-and-tumble environment of a real-world deployment. It's hard to test a program in all the places it might fail.

Say you've written an application that interacts with a remote database; how do you simulate what happens if the network connection drops out mid-query? Say you're trying to stress some code that mucks around in the file system; how to you test what happens when the machine loses power in the middle of an operation?

When it comes to Subversion's bindings, svnmock makes testing error conditions like these a snap.

svnmock allows you to create error triggers in much the same way as we allowed API calls earlier. This time, instead of the add_command method, we'll be using add_error.

>>> mock.add_error(svn.core.apr_initialize, (), \
        MemoryError)

Let's say you wanted to have the svn.core.apr_initialize call, which starts all Subversion-facing code, fail with a MemoryError. First, we have to tell svnmock that we're expecting this function to be called with no arguments. Then, instead of specifying a return value like we did with add_command, we give add_error an exception to raise. Note that we can specify an exception instance here as well:

>>> mock.add_error(svn.core.apr_initialize, (), \
        MemoryError("Ran out of memory"))

Now, we already saw what happens if a command assertion fails: svnmock blows up with a MockError exception. The same thing will happen with add_error if, say, svn.core.apr_initialize is given incorrect arguments, or another function is called in place of apr_initialize.

Next up, we'll talk about how to handle situations where you might need to exert a little less control over API calls. Dim the lights, put on some music, get into the lotus position: it's time to relax.