知道如何写出好的测试是关键，因为很容易写得不好。事实是，和其他所有一切一样，它需要实践。不过，这里有一些小贴士。
好的测试往往是简单的。它不会尝试一气呵成面面俱到。它的名字反映了它要的目的，并且名称应该精简成一句话。
确保测试不要过于指定。 过于指定的测试涉及到太多内部东西，并且不允许重构。
单元测试运行代码时会隔离其他测试，不一定是其他代码的测试。它将代码带出它的上下文，并创建其中一个方面的人工上下文，以便于进行调查。然而，这并不意味着单元测试必须得在隔离其他所有代码的情况下运行，尽管这通常被认为是“纯单元测试”。所有一切都没有必要mock和stub，因为只会导致更复杂的设置，更低的覆盖率和更加脆弱的测试。
在有意义的地方使用mock和stub。你不想对一个真正的HTTP API进行测试，那就stub。如果你正在测试的东西是你自己对该对象的调用，或你想要自己的代码历经某个路径，那么使用使用mock和stub。
测试读起来应该像一个小故事，遵循AAA体系： Arrange、Act、Assert。设置东西，做出声明，并且断言声明做了它应该做的。 “小故事”方面要重视小的方面。“3A”中没有一个应该超过3行代码以上。在阶段之间留一些空间会更好。应该没有任何分支和循环，你在断言时应该只涉及一个逻辑内容。 （如果一个断言语句就能表达自然是好，但有时你需要更多，那也没关系。）永远不要在测试的两个不同的地方断言，因为这会导致你实际测试的混乱。
测试应该只需要一些领域知识就可读。如果不深入模块的内部运作就很难解释的话，那么要么你最好多花一些时间在测试上，那么彻底弃之不顾。
一般情况下，不要测试依赖。对于某些项目，对一些代码所做的假设做一些简单的测试，可能是有意义的，但要谨慎和小心。测试库是库作者的工作。相反，要依靠更新日志进行升级，以及依赖于测试集成而不是库（不用mock一切的一个原因）。
编写不需要很长时间运行的低成本测试，因为要时常运行这些测试。如果你可以传递 --watch 参数到你的测试运行中，并且在每次有文件改变时运行它，那么这是一件好事。
最后但并非最不重要的一点是，使用你喜欢的测试框架。如果JavaScript是你的菜，那么我会推荐 AVA ，因为它清晰简单，而且没有复杂的配置。不管你选择什么，确保测试框架能和你一起工作，并帮助你编写测试更高效，更快捷。正如编码一样，如果你觉得不好玩，那么可能有什么地方出错了。