模拟还是存根?

发布于 2024-11-14 00:11:42 字数 598 浏览 6 评论 0原文

我有一个方法调用其中的其他两个方法。

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

我在单元测试方面经验不是很丰富,也从未使用过 Mocks 和 Stubs。

我不太确定如何为我的第一个方法创建单元测试。由于method_one和method_two多次访问数据库并且它们非常昂贵,因此我决定使用mox来创建模拟或存根,以消除访问数据库的需要。

如果有使用模拟和存根经验的人给我一些关于在我的案例中使用模拟和存根的提示,我将非常感激。

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 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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

南城旧梦 2024-11-21 00:11:42

在担心测试 main_method() 之前,首先测试较小的方法。考虑method_one()。为了讨论的目的,假设它存在于这样的类中:

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

为了在不访问数据库的情况下测试该方法,我们需要一个知道如何响应 all() 方法的对象。例如:

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

现在我们可以测试它:

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

这是一个基本的说明。现实世界往往更加复杂。为了值得编写测试的麻烦,您的模拟 all() 可能会做一些比返回常量更有趣的事情。类似地,如果 method_one() 包含一堆其他逻辑,我们的 MockQuery 可能需要更加精细——也就是说,能够适当地响应更多方法。通常,在尝试测试代码时,您会意识到原来的设计负担过重:您可能需要将 method_one() 重构为更小、定义更严格(因此更易于测试)的部分。

在层次结构中采用相同的逻辑,您可以创建一个 MockFoo 类,该类知道如何以简化的方式响应 method_one()method_two( )

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().

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文