如何编写单元测试而不是厌倦了FOSS项目的开发？

Question

我正在开发支持的跨平台项目：

• 四个C ++编译器 - GCC，MSVC，SunStudio，Intel，
• 五种操作系统：Linux，OpenSolaris，FreeBSD，Windows，Mac OS X。

我完全理解，如果没有适当的单元测试，就没有机会在所有这些平台上执行适当的QA。

然而，正如大家都知道编写单元测试非常无聊并且开发过程变慢（因为它很无聊并且开发FOSS软件不应该这样）

如何设法编写好的单元测试代码而不是停止编写代码。

如果你至少得到这份工资，你可以说 - 至少我得到了一些东西，但如果你不这样做，那就更难了！

澄清：

我知道TDD应该是关键，但TDD遵循非常严格的限制：

1. 您有确切的规格。
2. 您已完全定义了API。

对于以客户提供商风格开发的项目，情况确实如此，但演变的项目无法完成。

有时候为了决定我需要什么功能，我必须创造一些东西并理解它是否运作良好，如果API合适并且帮助我或它是丑陋的并且不满足我。

我认为开发过程更像是进化，而不是根据规范进行开发。因为当我开始实现某些功能时，有时我不知道是否 它会运作良好，它会使用什么样的模型。

这是与TDD相矛盾的完全不同的发展方式。

另一方面，对各种系统的支持需要进行单元测试以确保这一点 现有代码适用于各种平台，如果我想支持新的代码，我只需要 编译代码并运行测试。

Answer 1

我建议根本没有单元测试。对项目进行一些工作，看看它的发展方向。如果你没有足够的动力去做明显正确的事情，那么就可以对你的问题进行一些重构，一些bug修复和多个版本。然后，如果您看到弹出的问题，可以将TDD视为解决的可能工具之一。

问题可能是

• 低质量
• 高错误修复费用
• 不愿重构（即害怕改变现有代码）
• 次优API（API用于延迟更改）
• 高测试成本（即手动测试）

理论上知道单元测试和测试首先是正确的方法并经历痛苦和从该经历中学习之间存在很大差异。这种经历将带来动力。

TDD不是灵丹妙药。它可以以一种可怕的方式实施。它不应该成为项目核对清单中的复选框。

Answer 2

就个人而言，我觉得测试无聊。这是我第一次看到我的代码实际运行并发现它是否有效！

如果没有某种形式的测试程序直接运行新代码，我就不会看到它运行直到我构建了一个用户界面并将它们连接起来以通过UI提供新位然后，当它第一次不工作时，我必须尝试调试新代码，加上UI，加上将它们固定在一起的胶水，亲爱的上帝，我甚至不知道层该bug存在，更不用说尝试识别实际的违规代码了。甚至那么多，假设我还记得我在前往UI-land的旅行之前所做的工作。

正确的测试工具绕过所有这些并让我只需调用新代码，将任何错误本地化到测试的代码部分，这样就可以快速找到并轻松修复它们，看它能产生正确的结果，得到我的“它作品！”赶快行动，然后尽快转到下一段代码和下一次奖励。

Answer 3

写下他们从单元测试跳转到代码到单元测试再到代码......等等。

Answer 4

单元测试应遵循生产代码的所有最佳实践，例如DRY原则。如果你厌倦了编写单元测试，你也会厌倦编写生产代码。

测试驱动开发（TDD）可能对您有所帮助，因为您经常在编写单元测试和一些生产代码之间来回切换。

Answer 5

就个人而言，我发现我所知道的编写代码非常令人振奋。但如果你不想厌倦编写单元测试，那么你需要培养对调试的迷恋。

说实话，如果你认为编写单元测试很无聊又很慢，你真的需要重新解决你编写它们的方式。我建议你使用测试驱动开发进行调查。用编程语言编写测试并自动运行它们。使用测试的反馈来塑造您的代码。

在Kent Beck和Erich Gamma与JUnit合作的启发下，您可以提到几乎所有语言的Test First框架。维基百科关于TDD的文章有更多信息，包括一个有用的链接，指向按语言组织的框架列表。 Find out more

Answer 6

正如其他人告诉你的那样：首先编写测试会让它变得有趣。您不能对发展的项目进行的陈述需要重新考虑。实际上情况恰恰相反。如果您要使用敏捷路线，则非常不鼓励您事先定义所有内容。 TDD符合一种范式，即这是不可能的，并且会发生变化。一本非常清楚的书，并举例说明applying uml and patterns。

Answer 7

尝试使用TDD（测试驱动开发） - 而不是在实际编码完成后编写测试，然后再编写它们并让它们驱动您的设计。

由于项目的性质，需要相当多的自动化 - 找到一种方法为一个OS /编译器编写一次测试，然后为所有其他可用选项运行它。