2011-06-05 26 views
3

可能重复:
Hard-Coded Mock Objects vs Mocking Framework为单位惩戒对象测试

我想,我终于开始明白打算什么单元测试来解决,但我仍然有实现所有的麻烦的细节。我得出的结论是,我可能需要一个“模拟”(因为我不确定是否需要像Moq这样的整个框架)对象才能完成工作,所以我可能需要一个“模拟”(并且我轻松使用这个术语)。

作为我一直在运行的问题的一个示例,请考虑Repository Pattern(或类似)的实现。正如我目前所了解的那样,我需要(至少)对Add()Get()Remove()类方法中的每一个进行测试。这很好,除了我想测试Add()方法如何处理null引用。在这种情况下,我只需要在测试项目中定义一个简单的类,并在适当的单元测试中将其设置为null

例单元测试(插图):

+0

为什么不直接使用'object'? – 2011-06-05 08:58:42

+0

@Richard Szalay,工作原理是一样的。我使用'MockObject'的意图是让我知道我对模拟对象和预期用途的理解非常有限。在做了更多的研究之后,我开始认为'MockObject'应该是'StubObject'。我想我会拭目以待。 – 2011-06-05 09:42:12

回答

1

我会去尽量地说,软件测试,是像矩阵。没有人可以被告知什么是软件测试,你必须自己看看。大多数非信徒没有给出一个公平的机会,也从来没有尝试过做一些测试。欢迎来到俱乐部!

虽然测试的棘手问题是编写测试非常困难,但编写可测试的代码有时也很具挑战性。然而,今天有很多很棒的工具和技术,您应该投资成为一名更好的软件工程师。

嘲笑提供了你不得不自己写的傻瓜,嘲笑很方便。在这种情况下,您的存储库不是一个实际的持久性服务,它只是提供一个测试合同。如果不应该添加空引用,则应该有一个预期这种操作失败的测试用例。我相信这是不言而喻的,但对此进行测试很重要。

一个像Moq这样的库可能在这里非常有用,因为一个虚拟存储库什么都不做,而且你实际上需要在这里发生断言。我不明白在这里需要添加东西后属性Entity(除了可能使编写测试更容易)。但我也认为这是断言预期行为的错误方式。

在某种程度上,您所做的实际上是指集成测试,因为您不是在测试使用模拟工厂来测试两个组件之间交互的独立单元。这些类型的测试非常重要,但如果它们不是可测试的,也很难处理。这就是为什么我们有诸如依赖注入之类的东西。

你的问题并不需要特定的答案,但是你在正确的轨道上,我希望这会给你一些洞察力和进行软件测试时的额外信心。

+0

感谢您的见解。我继续在Moq上做了一些阅读,可以看到它对于快速原型(其中每个测试或多或少等同于可运行psuedocode)以及我想验证某个特定模拟对象的成员实际上是被调用或设置的。但是,我没有发现(并且认为在许多测试场景中会非常有用)是能够验证模拟对象成员中特定语句或调用的执行情况。 – 2011-06-05 13:16:15

+0

为了扩展这个想法......至少验证Add()方法中的特定语句是否被执行(或者更现实的是,在例程中达到了一个局部点),这对于非空值(以及反之亦然)。然而,我不确定这个功能在任何框架中都没有实现(尽管我可能错过了它)。 – 2011-06-05 13:18:44

+0

Moq没有使用这些记录/重放成语,甚至声称没有必要,我没有看到,但它可能值得检查。 – 2011-06-05 16:20:49