为什么要测试，测试是如何令人更快乐的？（二）

来源：教育联展网｜发布时间：｜编辑：佚名

来源：51Testing软件测试网

知道测试什么是关键
知道测试什么没有听上去得那么容易，并且有很大一部分是由经验所决定的。许多测试测试得太多。知道要测试什么涉及到要了解什么重要，什么不重要，而要知道这些并不是一件随随便便就能做到的事情。这里有一个技巧，但：
“尽可能采用**高级别的测试，以便于在实现上覆盖范围和灵活性。”——Brian Lonsdorf，《JavaScript. Air 004》
所以，基本上：
不要测试内部的东西，这只会成为你的阻碍。如果你真的觉得你应该测试内部的东西，那么你**分离成一个新的模块，使之成为外部的东西。
不要测试过于指定，或处理它们不必和不应该知道的东西。
不要只是为了获得 100％的覆盖率而去写测试。如果有人告诉你应该保持 100％的覆盖率，那么不要废话，揍他。
请记住，测试应该从模块外部的角度开始由外到内。需要注意的是完全覆盖的测试还是有可能的，即代码的所有分支应该都可以实现。如果没有，那么它们基本上是死码，不是吗？除非你需要更好地理解它们是如何工作的，否则就不要测试内部的东西。
想想当一段时间以后，代码重构的时候，会发生什么。实现应该允许在测试不失败的情况下被更改。为什么？因为如果将来的程序员需要改测试的话，那么基本上是重写，而不是重构。并且重写并不安全。对于重构内部应该没有新的测试。
在测试时要务实。测试是项目以及创造价值的一部分，什么都拿来测试没有任何意义，就像实现所有按钮没有意义一样。记住文档方面。如果测试涉及许多实施细节，那么我们就会失去模块的重点。我们就会失去文档的价值。
至于文档，测试你的领域假设。这些都是你工作的问题域的代码解释，这些问题域往往是一些程序员不擅长的地方。用代码的形式文档化这些假设解决了两个问题：自我文档化假设，并证明它们能够如解释那样有效工作。
当你发现 bug 的时候，编写测试。不要只是修复它。去写测试，确保它既是红的，又对齐 bug 所没有意识到的期望。修复 bug，使其呈现绿色。保存。
代码覆盖作为一个具体的数字被高估了，但作为一种工具它还是很有用的。不要为了覆盖范围而力求覆盖。请记住，覆盖范围只能告诉你测试在代码行运行什么，而不会告诉你测试将运行什么组合。不过，这可以成为事情是否朝着正确方向前进的一个很好的风向标。如果重构导致更糟的代码覆盖范围，那么就应该响起警铃，尤其是如果它是重构的话。不要只是为了增加覆盖数值就让自己去编写测试。经过充分测试和编写良好的代码的覆盖数值更大。
编写测试的触发器是当你的代码片段有新的行为的时候。测试应该盯牢这种行为，但不要矫枉过正。
测试库可能比测试终端应用程序更容易，更为重要。毕竟，库会被多个应用程序使用。
如何编写特别棒的测试
知道如何写出好的测试是关键，因为很容易写得不好。事实是，和其他所有一切一样，它需要实践。不过，这里有一些小贴士。
好的测试往往是简单的。它不会尝试一气呵成面面俱到。它的名字反映了它要的目的，并且名称应该精简成一句话。例如，名称不应该是“it works”，而是“it returns 0 for negative values”。
确保测试不要过于指定。过于指定的测试涉及到太多内部东西，并且不允许重构。
单元测试运行代码时会隔离其他测试，不一定是其他代码的测试。它将代码带出它的上下文，并创建其中一个方面的人工上下文，以便于进行调查。然而，这并不意味着单元测试必须得在隔离其他所有代码的情况下运行，尽管这通常被认为是“纯单元测试”。所有一切都没有必要 mock 和 stub，因为只会导致更复杂的设置，更低的覆盖率和更加脆弱的测试。
在有意义的地方使用 mock 和 stub。你不想对一个真正的 HTTP API 进行测试，那就 stub。如果你正在测试的东西是你自己对该对象的调用，或你想要自己的代码历经某个路径，那么使用使用 mock 和 stub。
测试读起来应该像一个小故事，遵循 AAA 体系： Arrange、Act、Assert。设置东西，做出声明，并且断言声明做了它应该做的。 “小故事”方面要重视小的方面。“3A”中没有一个应该超过 3 行代码以上。在阶段之间留一些空间会更好。应该没有任何分支和循环，你在断言时应该只涉及一个逻辑内容。（如果一个断言语句就能表达自然是好，但有时你需要更多，那也没关系。）永远不要在测试的两个不同的地方断言，因为这会导致你实际测试的混乱。
测试应该只需要一些领域知识就可读。如果不深入模块的内部运作就很难解释的话，那么要么你**多花一些时间在测试上，那么彻底弃之不顾。
一般情况下，不要测试依赖。对于某些项目，对一些代码所做的假设做一些简单的测试，可能是有意义的，但要谨慎和小心。测试库是库作者的工作。相反，要依靠更新日志进行升级，以及依赖于测试集成而不是库（不用 mock 一切的一个原因）。
编写不需要很长时间运行的低成本测试，因为要时常运行这些测试。如果你可以传递 --watch 参数到你的测试运行中，并且在每次有文件改变时运行它，那么这是一件好事。
**后但并非**不重要的一点是，使用你喜欢的测试框架。如果 JavaScript. 是你的菜，那么我会推荐 AVA，因为它清晰简单，而且没有复杂的配置。不管你选择什么，确保测试框架能和你一起工作，并帮助你编写测试更高效，更快捷。正如编码一样，如果你觉得不好玩，那么可能有什么地方出错了。