测试驱动开发适当性

Question

我知道测试驱动的软件开发有许多优点。但是，我想知道在某些情况下，测试驱动的开发是不合适的，还是根本不可行。

Answer 1

我认为TDD对我来说一般是不切实际/不可行的，因为我使用的是一个16位的uC。在我的构建环境中没有直接编译的开源测试工具，而且专有的解决方案是昂贵的。其余的答案将是嵌入式C中的w.r.t.tdd。

我正在研究詹姆斯·格伦宁的书，他用cpputest和cunit作为他的例子。这两种环境的问题在于，我需要维护两个独立的构建环境-- GCC+Cygwin，然后是我的正常构建环境。我的另一个选择是在C++测试工具上进行大量的重新工作，以使它在我的构建环境中编译，这个环境只支持C++的一个有限子集。对于我的开发团队来说，这不是一件很好的事情。

但后来我发现，让我自己的轻量级单元测试工具嵌入到我的项目中是多么的简单。，我们走吧！我能够在几天内做出自己的测试工具，通过重新定义断言宏来支持测试断言，允许我测试声明为静态的函数，甚至允许动态函数挂起。当我在模拟器中运行代码时，我的IDE可以让我知道我的代码覆盖率是什么，这样我就可以在模拟器中判断我的基础是否覆盖了，然后在目标上再次运行相同的测试。

因此，对于我的应用程序来说，TDD对于大多数应用程序都是可行的。但是，我认为对于一个INIT函数来说，如果代码流是完全线性的，那么它就没有多大意义了，例如，只需要为寄存器编写常量来设置cpu时钟、uart波特率等等。检测测试来查看是否将值写入正确的位置是徒劳无功的。在集成测试期间，该功能在目标上更容易检查。您很快就会知道，当您获得的所有数据都是垃圾时，您的波特率寄存器没有正确设置。

但这涉及到其他一些技术，如按合同设计。您可以输入断言来断言UART缓冲区不会溢出，或者不会出现帧错误。当您在目标上测试代码时，这会很快告诉您是否存在配置问题，这比知道“我将这个数字写到某个点并从其他位置读取预期的内容”更有价值。实际上，您将验证配置的正确性，而不是您是否能够将某些内容写入内存地址。