unit-testing - 具有大量用例的单元测试

Question

我正在开发一个有很多用例的 Java 应用程序。应用程序的输入是在不同时间发生的不同类型的事件。这种输入产生了数百个测试用例。有没有人遇到过这种情况？在向 QA 团队发布之前，您是否确保涵盖了所有测试用例？
所以我的问题是:测试具有大量测试用例的程序的最佳方法是什么？

Answer 1

不要试图从一开始就用单元测试覆盖整个应用程序。以小的、渐进的步骤进行。设置一个小里程碑，在一两周内完成，然后开始为该里程碑的第一个功能编写测试。然后开始实现该功能。它应该是这样的:

小而渐进的步骤

将应用程序分解为您可以看到的更小的功能里程碑 那一刻

选择必须实现的最紧迫的功能 那一刻

将该功能分解为较小的任务

为其中一项任务编写测试

运行测试。它应该失败( RED )。如果它通过你的测试就坏了。

开始编写最少的代码，以便该测试通过。允许使用硬编码值。

运行测试 ( 绿色 )。它们应该通过(尤其是在使用硬编码值时)。现在您知道您有一个用于 future 重构的安全网。

如果需要，开始重构( REFACTOR )您的代码，否则转到第 4 步。

准备改变

这种方法的优点是将一项巨大的任务分解成可管理的部分，它让您有机会在一两周内完成某件事。稍后，管理层可能会重新考虑他们的优先事项，您必须从上面的第一点重新组织列表。另一个优点是，每一步都有一个单元测试来支持你，让你有信心，感觉你确实在完成某件事，而且你实际上可能比你想象的更快地向管理层交付一些东西，因为在每一步你都有一个 (有点)您程序的工作版本。他们可以看到进步，这对你和他们都很重要。他们看到工作实际上正在完成，并且您会获得应用程序所需的反馈(需求总是在变化，让我们尽早让它们保持变化)。

如 Gren说，您可能将用例与单元测试混淆了。用户可能对应用程序采取的操作也可以由域模型中的单个方法处理。所以情况可能并没有看起来那么糟糕。

没有预先设计，即使是单元测试

无论如何，不​​要试图从一开始就编写所有测试。这就是我做的方式，这是一个很大的失败。一旦你进行了小的迭代(测试方法/方法实现)，你就会变得更有效率和自信。在预先编写所有测试时，您可能会注意到，由于使您的第一个测试通过所必需的分解，您需要重新考虑您在编写测试时所设想的整个 API，而在编写测试时，然后是实现，一个测试，然后是实现，你最终会得到所谓的紧急设计。这是最好的设计。设计模式就是这样出现的。设计模式不是一个整天站着思考解决问题的方法的人。