应用 TDD 时是否有无法测试的东西 [关闭]答案

【问题标题】：Are there things that you can't test when applying TDD [closed]应用 TDD 时是否有无法测试的东西 [关闭]
【发布时间】：2019-08-04 21:16:37
【问题描述】：

我一直在将 TDD 应用于一些新项目以掌握事情的窍门，并且我了解基本流程：编写失败的测试，编写代码以通过测试，如果需要进行重构，重复。

为了保持测试的快速和解耦，我将网络请求和文件 I/O 等内容抽象出来。这些通常被抽象为使用依赖注入传递的接口。

通常开发非常顺利，直到我意识到我需要实现这些抽象接口。抽象它们的全部意义在于使其易于测试，但是按照 TDD，我需要在编写实现代码之前编写测试，对吗？

例如，我正在查看 tdd-tetris-tutorial https://github.com/luontola/tdd-tetris-tutorial/tree/tutorial/src/test/java/tetris。如果我想添加使用键盘的功能，我会将基本控件抽象为 Controller 类中的方法，例如可以测试的“rotateBlock”、“moveLeft”等。

但最后，在实现控制器类时，我需要添加一些逻辑来检测来自键盘的击键。如何编写测试来实现它？

也许有些东西无法测试，在某些情况下不可能达到 100% 的代码覆盖率？

【问题讨论】：

【解决方案1】：

也许有些东西是无法测试的，在某些情况下达到 100% 的代码覆盖率是不可能的？

我使用的拼写略有不同：并非所有事物都可以在相同的成本效益水平上进行测试。

可以这么说，“诀窍”是将您的代码分为两类：易于测试的代码，以及不需要测试或不经常测试的显而易见的代码。

简单适配器的好处是（一旦你让它们工作了）它们通常不需要太多改变。所有逻辑都存在于其他地方，而其他地方易于测试。

例如，考虑从文件中读取字节。这种接口看起来有点像一个函数，它接受一个文件名作为参数，要么返回一个字节数组，要么返回某种异常。实现在大多数语言中是一个直接的练习，并且代码是如此熟悉，以至于它显然属于“如此简单，显然没有缺陷”的类别。

由于代码简单且稳定，您无需以接近您定期重构代码的测试频率对其进行测试。因此，成本效益分析支持这样的结论，即您可以将此代码的偶尔测试委托给更昂贵的技术。

100% 的语句覆盖率从来都不是 TDD 的目标（尽管很容易理解您——以及无数其他人——是如何得出这个结论的）。这主要是关于推迟详细设计。所以在某种程度上，从一开始就很简单且不经常更改的代码是“越界”的。

【讨论】：

【解决方案2】：

您无法使用 TDD 单元测试测试所有内容。但是如果你也有集成测试，你可以测试那些 I/O 接口。您可以使用 TDD 生成集成测试。

在实践中，自动测试有些事情是不切实际的。对一些罕见的错误条件或竞争危险的错误处理是最难的。

【讨论】：