Tell me more ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.
up vote 4 down vote favorite
1

I am testing an app that does some subversion interactions, such as comitting, adding, stat, etc.

What's a good way to get me started in terms of mocking the subversion client and working directory that I use etc. This would be in Python.

So, for example, when I check whether a repository is a valid repository, I try to make an http connection to the network resource. Do I 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 etc? Am I on the right path?

share|improve this question
I'm sorry... when I read this question, all I can think of is "Look at me! i'm a stupid SVN! See how dumb I am!" kind of mocking... oy, it's been a long day... – TristaanOgre Jun 1 '11 at 20:33
When I first read this question, I asked myself why would anyone want to 'mock' SVN? The purpose of a mock is to simulate an object when the 'real' object is not available or impractical to use. IMHO, Writing a mock of SVN doesn't seem to be a cost effective solution since you can get SVN for free. As with Dale, I am confused over who is throwing and who is catching (or rethrowing) 'the exception.' – Bj Rollison Jun 2 '11 at 14:39
@BJ: It's true that SVN doesn't cost money. It does cost time, which can be precious in an automated test suite. Any code that directly uses the file system or the network can significantly increase the execution time of the test. If enough tests use such slow resources, your suite begins to crawl, and the feedback delays become troublesome. It's common to mock that kind of code, especially in unit tests, but also in acceptance tests from which you want very fast feedback. – Dale Emery Jun 2 '11 at 18:58
@Dale, the cost factor is in ref. to the cost of setting up SVN in a clean room env. for testing purposes, versus the cost of coding and maintaining mock objects. I understand value of mocks esp. in unit testing, and also the risks (e.g. mocks model functionality, and may provide false negatives) Also, at some point the mocks have to be replaced with the real thing. IHMO, in this case it is 6 of one thing and half dozen of another since we don't really know complete story. :-) – Bj Rollison Jun 3 '11 at 3:35

1 Answer

up vote 7 down vote accepted

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:

  1. Write a test to cause your app to interact with SVN in one of its possible ways
  2. Write your mock to respond in one of its possible ways
  3. 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...
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.