嘲笑还是不嘲笑？

Question

据我所知，从极限编程和单元测试中，测试必须由另一个开发人员在另一个开发测试方法之前完成（或者来自相同的开发人员，但测试必须在方法实现之前编写）。

好吧，看起来不错，我们只需要测试一个方法是否具有良好的行为，当我给它一些参数。

但理论和实践之间的区别在于，在理论上不存在但在实践中有...

的第一次，我试图测试，我发现它在某些情况下很难由于对象之间的关系。我发现嘲笑的做法，我发现它非常有用，但一些概念让我怀疑。

首先，嘲讽隐含的说：“你知道该方法如何运行，因为你必须知道它需要什么其他对象......”。那么，从理论上讲，这是我的朋友鲍勃写的测试，他只知道，当我给它“john”字符串时，该方法必须返回true ...这是我使用dao代码访问数据库而不是使用散列表在内存中...

我的可怜的朋友Bob会如何写测试？他会期待我的工作......

好吧，似乎不是纯粹的理论，但无论如何。但是，如果我看看很多模拟框架的文档，它们允许我测试一个方法被调用的次数和顺序！ ouch ...

但是，如果我的朋友鲍勃必须测试这种方法，以确保良好的依赖关系，方法必须写在测试之前，不是吗？

哼...帮助我的朋友鲍勃...

我们什么时候停止使用模拟装置（为了验证等）？ 当模拟机制有用吗？ 理论，实践和模拟：什么是最好的平衡？

Answer 1

您的描述中似乎缺少的是将合同与实施分离的概念。在C＃和Java中，我们有接口。在C++中，仅由纯虚函数组成的类可以填充此角色。这些并不是真的必要，但有助于建立逻辑分离。因此，除了您似乎遇到的困惑之外，练习应该更像是：Bob为一个特定类/功能单元编写单元测试。在这样做的时候，他为其他类/单元定义了一个或多个接口（合同），以支持这个接口。他现在不需要写这些东西，而是用模拟对象填充它们以提供他的测试和被测系统所需的间接输入和输出。因此，一组单元测试的输出不仅仅是驱动单个单元开发的测试，还需要其他代码支持正在开发的单元需要执行的合同。

Answer 2

我不确定究竟是什么问题。所以我可能无法准确回答这个问题，但我会试一试。

假设你正在书写系统中，其中一个需要获取数据（假设为简单起见String）从供应商，然后逆该字符串，并将其发送到另一个系统下

B和C提供给你，他们实际上是接口，现实生活中的实现可能是BImpl和CImpl。

为了您的工作目的，您知道，您需要从系统B调用readData（），并从系统C调用sendData（String）。您的朋友Bob也应该知道，您不应该发送你得到它之前的数据。此外，如果你得到“abcd”，你应该发送“dcba”

看起来你和Bob都应该知道这一点，他写测试，然后编写代码......问题在哪里？

当然现实生活是比较复杂的，但你应该仍然能够用单元测试的简单交互来建模。

Answer 3

当你正在编写一个单元测试时，你正在测试结果和/或测试中的类别的行为，结果和/或行为是否与预期的相符。

期望会随着你开发这个类的时间而改变 - 新的需求可能会在这种改变中产生类的行为或者调用特定方法的结果。它永远不会成为石头和单元测试，并且被测试的类将一起演变。

最初，您可能会从一个非常精细的级别开始几个基本测试，然后演变成越来越多的测试，其中一些测试可能对测试的类的实际实现非常特殊（至少如就该类别的可观察行为而言）。

在某种程度上，您可以针对被测试类中的原始存根编写出很多测试，这会产生预期的行为，但大多尚未实现。然后你可以重构/开发“真实”的课程。

在我看来，尽管在开始时编写所有的测试，然后全面开发课程，但这是一个梦想 - 根据我的经验，测试和受测试的课程一起演变。 也可以由也由同一个开发者编写。

然后，我当然不是TDD纯粹主义者，只是试图以务实的方式充分利用单元测试。

Answer 4

我不确定我是否理解你的问题。

使用mock验证对象之间的协作。例如，假设您有一个使用用户名和密码的Login（）方法。现在假设您想要此方法尝试登录失败的登录。在你的单元测试中，你将创建一个模拟记录器对象，并设置它将被调用的期望。然后，您会依赖注入到您的登录类中，并使用错误的用户名和密码调用您的Login方法来触发日志消息。

您单元测试工具包中的其他工具是存根（stub）。当你不测试协作时使用存根，而是伪造依赖关系，以便让测试的类可以运行。

罗伊Osherove，该单元测试的艺术的作者，有嘲笑好的视频：TDD - Understanding Mock Objects

此外，我建议去他的网站http://artofunittesting.com/和下看右侧的免费视频标题为“单元测试视频”。