Mocks or Stubs?

I have a method that calls two other methods in it.

def main_method(self, query):
  result = self.method_one(query)
  count = self.method_two(result)
  return count

def method_one(self, query):
  #Do some stuff based on results.
  #This method hits the database.
  return result

def method_two(self, result):
  #Do some stuff based on result.
  #This method also hits the database.
  return count

I'm not very experienced at unit testing and have never worked with Mocks and Stubs.

I'm not too sure how to create a unit test for my first method. Since method_one and method_two hit the 开发者_JAVA百科database many times and they are very expensive, I have decided to use mox to create a mock or stub in order to eliminate the need of hitting database.

I would really appreciate it if someone who has experience working with Mocks and Stubs give me some hints on using mocks and stubs for my case.

---

Before worrying about testing main_method(), first test the smaller methods. Consider method_one(). For the purpose of discussion, let's say it exists in a class like this:

class Foo(object):
    def method_one(self, query):
        # Big nasty query that hits the database really hard!!
        return query.all()

In order to test that method without hitting the database, we need an object that knows how to respond to the all() method. For example:

class MockQuery(object):
    def all(self):
        return [1,2]

Now we can test it:

f = Foo()
q = MockQuery()
assert f.method_one(q) == [1,2]

That's a basic illustration. The real world is often more complicated. In order to be worth the trouble of writing the test, your mock all() would likely do something more interesting than return a constant. Along similar lines, if method_one() contains a bunch of other logic, our MockQuery might need to be more elaborate -- that is, capable of responding appropriately to more methods. Often while trying to test code you realize that your original design was overburdened: you might need to refactor method_one() into smaller, more tightly defined -- and thus more testable -- parts.

Taking the same logic a step up in the hierarchy, you might create a MockFoo class that would know how to respond in simplified ways to method_one() and method_two().