有没有一个坏的单元测试？

Question

鉴于您无法为动态内容编写测试，除此之外，您是否有理由不添加单元测试？也许测试项目的完整性可能被认为是不必要的，但我可以两种方式争论。

示例： 的

Objective-C / xCode =写一个测试来确保你的常量中列出的字体也列在你的项目info.plist UIAppFonts数组中。

Answer 1

从技术上讲，测试应该遵循一些关键指标：它们应该快速，易于阅读和解释，结果一致等。

如果不符合良好单元测试的任何这些（和更多）质量，您将最终获得成本。如果单元测试速度慢，那么你花时间大拇指，或者如果它们太难，你会花时间解释测试而不是编写新的代码/代码，对于结果不一致的测试也是如此。

因此我们可以说存在不良的单元测试。

但是，如果我们研究一下“我们应该测试X”的具体例子，那么这就更加主观了。

如果像getter / setter（又名：普通代码）那样容易测试某些东西，那么有些人可能觉得不值得花时间而其他人认为没问题：通过添加这些快速，小的测试你永远不会遇到意想不到的问题只是因为有人为他们的getter / setter添加了逻辑，并且没有测试可以捕获任何错误。

我对Objective-C一无所知，但乍一看似乎是一个合理的概念来测试。

一般规则：除非您有明确的理由不进行测试，否则请对其进行测试。

Answer 2

单元测试实际上只是为代码质量创建较低水印的工具。

如果您100％确信您的代码按预期工作，那么您就有足够的单元测试。在这种情况下添加更多测试只是浪费时间。

想想“你好世界”。你会为此写多少单元测试？ 1还是0？

如果你对某些事情不确定，那么你需要更多的单元测试。这种感觉的原因可能是：

1. 您或其他人发现了一个错误。总是为bug编写单元测试。
2. 有人要求提供新功能，而您对如何实施并不自信 - ＆gt;编写测试来设计API，并确保最终结果符合预期（并确保每个人都知道并同意预期）。
3. 您正在使用新技术并想要记录a）它是如何工作的以及b）您如何使用它。当你后来想知道“我是怎么做到的？”时，这些测试就像一种模板。
4. 您刚刚在您使用的库中发现了一个错误。当您修复错误时，您还应该添加一个测试用例，告诉您“此错误现已修复！”所以你以后不要在错误的地方打猎。

坏单位测试的例子：

1. 隐藏在单元测试中的集成测试
2. 测试setter和getter
3. 残疾人单元测试
4. 注释单元测试
5. 每天或每周打破一次的单元测试（它们会削弱您的信心并且您愿意编写单元测试）
6. 任何执行时间超过10秒的测试
7. 长度超过50行的单元测试（包括所有设置代码）

Answer 3

我的回答是肯定的，编写测试仍然是编写代码，避免错误的最好方法是不首先编写代码。

恕我直言，编写好的测试通常比编写好的代码更难。在理解问题之前，你不能编写一个可用的测试，无论是它应该如何工作以及它如何失败。前者通常比后者更容易理解。

说完了所有这些，你必须从某个地方开始，有时候最简单的方法是先编写最简单的测试，即使那时候真的没有测试任何有用的东西。 但是，在进行TDD过程时，您应该将这些测试结果列出来。努力建立一个仅记录对象外部接口的测试集。这很重要，因为当您回到对象以供以后重构时，您需要一组测试来定义对象对程序其余部分的责任，而不是对象对其自身的责任。

（即您想要将对象的输入和输出测试为“黑匣子”，而不是对象的内部布线。这样您就可以自由地更改w / o，从而造成对象外部的损坏。）