Yes, you're on the right path (though I have a caveat or two).
More generally than "raise the right exception": The tactic is to make sure that no matter how SVN responds to your app's commands, your app responds as you wish.
For me, the biggest challenges when mocking third-party code is to characterize:
- All the ways my code uses the third-party code
- All the ways the third-party code might respond to my uses.
- How you want your app to respond in each of those situations.
But once you've characterized those things, mocking is generally straightforward:
- Write a test to cause your app to interact with SVN in one of its possible ways
- Write your mock to respond in one of its possible ways
- Verify that your app responds as planned.
One caveat. I'm not sure what you mean by "check what Exception is thrown in my app if I try to connect to a non-existent resource and just make my mock client raise that exception." It sounds as if (in that situation, at least) your app simply passes the SVN exception on to its users. If that's just one example of how your app responds, okay. But if you meant that as a general thing (i.e. "my app always passes SVN exceptions on to its users"), I don't know whether that's the right thing to do or not.
The key is to make the mock raise whatever exception the real SVN would raise in that situation, and verify that your app does the right thing in response. Your app's job might be:
- Pass the SVN exception on to your app's users (as in your example)
- Throw a new, more descriptive exception, given your code's knowledge of what it was doing at the time (I prefer this when I can identify or invent a more meaningful exception)
- Retry the connection
- Switch to some other means of connecting
- Something else...