如何编写单元测试而不是厌倦了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

我建议根本不进行单元测试。稍微研究一下这个项目，看看它会带来什么结果。如果你不能投入足够的动力去做明显正确的事情，那么就解决你的问题，进行一些重构、一些错误修复和多次发布。如果您看到出现了哪些类型的问题，请将 TDD 视为解决这些问题的可能工具之一。

问题可能是

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

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

TDD 并不是万能药。它可以以一种可怕的方式实施。它不应该成为项目检查列表中的复选框。

Answer 2

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

如果没有某种形式的测试程序来直接运行新代码，我就无法看到它运行，直到我构建了一个用户界面并将其全部连接在一起以通过 UI 提供新位，然后，当它第一次不起作用，我必须尝试调试新代码，加上 UI，加上将它们粘合在一起的粘合剂，亲爱的上帝，我什至不知道错误在哪一层，更不用说尝试了识别实际的违规代码。即便如此，前提是我仍然记得在去 UI 世界旅行之前我正在做什么。

正确的测试工具可以绕过所有这些，让我只需调用新代码，将任何错误本地化到代码的测试部分，以便可以快速找到并轻松修复它们，看看它是否产生了正确的结果，让我“它有效！” 冲，并尽快继续下一段代码和我的下一次奖励冲刺。