如何更好的写单元测试

原文链接
不久前在工作上广泛的做一些单元测试，我收集了一些指导方针以便让我更好的尝试坚持在这些年来写更好的测试。记住差劲的编写测试是一个浪费时间的事和会在测试的道路上引起重要的问题。所以最好就是在我们的思想上保持一些编写单元测试的指导方针。

• 单元测试不应该被写成通过 单元测试应该写成失败，你可以写其中一些通过的测试在几分钟内，但你只是在欺骗你自己而已。

• 测试应该只测试一件事 你应该测试一个方法和一个方法，如果不是这样，那么你可能违反了单一原则

• 你的测试应该通熟易懂 确定他们的评论很容易明白，就好像任何其他代码一样。

• 良好的命名约定 此外测试应该像任何其他代码一样，容易让任何人都能够看得懂。

• 断言是需要分开行动的 你的断言应该寻找一个结果，而不是执行逻辑结构。

• 使用具体的输入 不要使用任何的动态的数据区输入，就好像日期 date()可以引入变异。

• 团体测试的位置 从逻辑上的角度而言，这个让工作很容易找到当他们没有错误指向那个问题。

• 好的测试需要隔绝一切东西 你不应该依赖其他的测试和环境的配置等等。这些创造了很多个故障点。

• 不要包含私有的方法 他们的实现不应该包含在测试单元里面。

• 不要连接数据库或者是数据源 这个是不可靠的，因为你不能确信那个数据的存在将会永远是不改变的，这个将会创造故障点。

• 不要多于一个模拟在每一个测试上 我们将会再一次的排除故障点和矛盾。

• 单元测试不是集成测试 你想要测试一些结果，不要执行单元测试。

• 测试一定是要确定的 你应该需要一个明确的结果，如果你只是通过一些数据而已那么干脆不要。

• 保持你的测试幂等（?) 在不改变一些结果的情况下你应该能够多次运行这个测试，和你应该不改变任何数据或者增加任何东西。在一次或者n次的测试应该具有相同的结果。

• 每次测试的时候都应该只测试一个类或者只测试一个方法 一个有组织的方法用来查明问题当问题出现的时候，更好的在测试中帮助你识别依赖的关系。

• 在你的测试中应该包括意外 你应该使用意外和不要忽略意外的存在。

• 不要用你自己的测试去测试第三方的功能库 很多高质量的库应该拥有他们自己的测试。如果不考虑模拟产生的一致性结果。

• 应该要限制值 使用值的时候要注意限制和设定最大值和最小值的一致性。

• 测试不应该需要配置和自定义设置 每个人都应该可以使用你的测试来工作，只能工作在我的机器上理论上在这里不适用。

我希望这个在 单元测试对 你的学习上和工作上有帮助。