问题标签 [tdd]

我在 RhinoMocks 中使用一个模拟对象来表示一个调用 MessageQueue.GetPublicQueues 的类。我想模拟消息队列在工作组模式下运行时抛出的异常，即MessageQueueException，以确保我正确捕获异常

MessageQueueException 没有公共构造函数，只有标准的受保护异常构造函数。有没有合适的方法从模拟对象/Expect.Call 语句中抛出这个异常？

单元测试对我来说听起来很棒，但我不确定我是否应该花时间真正学习它，除非我能说服其他人认为它具有重要价值。我必须说服其他程序员，更重要的是，说服管理中的 bean-counters，所有花在学习测试框架、编写测试、更新测试等的额外时间都会为自己付出代价，然后是一些。

有什么证据？有没有人真的用两个独立的团队开发过相同的软件，一个使用单元测试，另一个不使用，并比较结果？我对此表示怀疑。我是否应该用“在互联网上查找它，每个人都在谈论它，所以它一定是正确的做法”来证明它的合理性？

让外行相信单元测试值得付出努力的确凿证据在哪里？

我在 MVCStoreFront 应用程序上观看 Rob Connerys 的网络广播，我注意到他正在对最平凡的事情进行单元测试，例如：

会有一个像这样的测试：

虽然，我完全支持单元测试，但我有时想知道这种形式的测试优先开发是否真的有益，例如，在实际流程中，您的代码上方有 3-4 层（业务请求、需求文档、架构文档） ，其中实际定义的业务规则（折扣价格是价格 - 折扣）可能被错误定义。

如果是这种情况，那么您的单元测试对您来说毫无意义。

此外，您的单元测试是另一个失败点：

现在测试有缺陷。显然在一个简单的测试中，这没什么大不了的，但是假设我们正在测试一个复杂的业务规则。我们在这里得到什么？

快进两年应用程序的生命，维护开发人员正在维护它。现在业务改变了它的规则，测试又中断了，一些新手开发人员错误地修复了测试……我们现在又遇到了一个故障点。

我看到的只是更多可能的失败点，没有真正的收益回报，如果折扣价格错误，测试团队仍然会发现问题，单元测试如何节省任何工作？

我在这里想念什么？请教我热爱 TDD，因为到目前为止我很难接受它是有用的。我也想，因为我想保持进步，但这对我来说没有意义。

编辑：有几个人一直提到测试有助于执行规范。根据我的经验，规范也经常出错，但也许我注定要在一个规范是由不应该编写规范的人编写的组织中工作。

我正在努力分离以下代码中的依赖项：

本质上，我想在不依赖外部网站请求的情况下进行单元测试。

解决这个问题的最佳方法是什么？

我们正在构建一个可供其他开发人员使用的框架，目前我们一直在使用大量的 TDD 实践。我们到处都有接口，并且有编写良好的模拟接口的单元测试。

然而，我们现在已经达到了输入类的一些属性/方法需要是内部的，并且对我们的框架用户不可见的地步（例如对象 ID）。那么问题是我们不能将这些字段/方法放在界面上，因为界面没有描述可访问性。

我们可以：

1. 在方法的第一行仍然使用接口和向上转换，但这似乎违背了接口的目的。
2. 使用类作为输入参数——打破一切都应该是接口的 TDD 规则
3. 提供另一层，在公共接口和内部接口之间进行一些转换

是否有现有的模式/方法来处理这个问题？TDD 人们说应该做什么？

我知道测试驱动开发的定义原则之一是您首先编写单元测试，然后编写代码以通过这些单元测试，但是有必要这样做吗？

我发现在编写之前我常常不知道我在测试什么，主要是因为我过去从事的几个项目更多地是从概念证明而不是设计出来的。

我以前尝试过编写单元测试，它可能很有用，但对我来说似乎并不自然。

测试驱动开发人员指的是一种快速的、探索性的调查，其中涉及对某些东西进行编码以查看它是否有效，这是一个尖峰。

任何想法为什么他们想出了这个词？

更新： Kent Beck 的造币在我看来就像是“原版”，尽管在我看来他对这个词的使用没有多大意义。编写一个快速测试是“在项目中增加一个峰值”？

有趣的是，他似乎停止使用这个词，因为它给不同的人带来了不同的含义——见下文以获得证据！

我正在构建一个包含一些公共和私有方法的类库。我希望能够对私有方法进行单元测试（主要是在开发时，但它也可能对未来的重构有用）。

这样做的正确方法是什么？

我最近开始使用代码覆盖工具（特别是 Emma 和 EclEmma），我真的很喜欢它给我的单元测试完整性的观点——以及查看单元测试的代码区域的能力。根本不打。我目前在一个不做大量单元测试的组织工作，我计划真正推动每个人进行单元测试和代码覆盖率和 TDD，并希望转换组织。

对于这个主题，我不确定的一个问题是我应该将代码覆盖率到底有多远。例如，如果我有这样的课程：

我编写了一些简单的单元测试以确保它equals()正常工作，getValue()返回我所期望的等等。但是由于 EclEmma 的视觉特性，该hashcode()方法显示为“未测试”的鲜红色。

hashCode()在这个例子中，考虑到实现有多简单，是否值得费心去测试？我觉得我会为这个方法添加一个单元测试，只是为了提高代码覆盖率，并摆脱 EclEmma 在这些行中添加的刺眼的红色突出显示。

也许我是神经质和强迫症，但我发现使用像 EclEmma 这样的东西可以很容易地看到未经测试的内容 - 该插件以红色突出显示源代码，并以绿色突出显示代码 - 真的让我想要尽可能多地获得 100% 绿色的课程——即使它不会增加太多好处。

我听说使用 TDD 开发的项目更容易重构，因为这种做法产生了一套全面的单元测试，如果任何更改破坏了代码，这些测试将（希望）失败。然而，我所看到的所有示例都涉及重构实现——例如，用更有效的算法更改算法。

我发现重构架构在设计仍在制定的早期阶段更为常见。接口发生变化，添加和删除新类，甚至函数的行为也可能略有变化（我以为我需要它来做这个，但它实际上需要做那个）等等......但是如果每个测试用例都是紧密耦合的对于这些不稳定的类，您不是每次更改设计时都必须不断地重写您的测试用例吗？

在 TDD 中什么情况下可以更改和删除测试用例？您如何确保更改测试用例不会破坏它们？另外，似乎必须将全面的测试套件与不断变化的代码同步会很痛苦。我知道单元测试套件可以在维护期间提供巨大帮助，一旦软件构建、稳定和运行，但这是在游戏后期，而 TDD 也应该在早期提供帮助。

最后，一本关于 TDD 和/或重构的好书会解决这些问题吗？如果是这样，你会推荐哪个？