测试代码时你可能会犯的11个错误

我遇到的大多数开发人员都不怎么热衷于测试。有些会去做测试，但大多数都不测试，不愿意测试，或者勉而为之。我喜欢测试，并且比起编写新的代码，愉快地花更多的时间在测试中。我认为，正是因为专注于测试，我才可以花更少的时间来编写新的代码或修复bug，并且非常有成效。

如果你不确定要不要编写测试或者并不常写测试，那么，下面这些内容将指导你往一个更好的方向发展。

1、没有测试

我们很容易毫无原因地掉入这个陷阱。从现在开始，制定计划添加测试到你现在正在处理的代码中，并添加测试到将来的项目中。

2、没有从项目一开始就启动测试

我们很难再回过头去添加测试，并且可能需要改变架构才能添加测试，这样做最终将需要你花更长的时间才能产出可信任的代码。从一开始就在项目的生命周期添加测试可以节省时间和精力。

3、编写失败的测试

TDD方法的普及将红—绿—重构的理念带到软件测试世界。这个理念常常被误认为应该“通过编写一个失败的测试开始”。其实并非如此。在写代码之前创建测试的目的是定义系统的正确行为应该是什么。在许多情况下，它是一个失败的测试（红色表示），但它可能会通过一个非决定性的或未实现的测试来表示。

4、担心未实现测试

软件开发中的一个大问题就是，代码和任何关于系统实际上应该做什么的文档之间的沟壑。通过拥有一个名称中明确定义你最终想要实现的预期行为的测试，你将从测试中得到一定的价值，即使将怎么写测试目前还不得知。

5、没有很好地命名测试

命名软件这件事出了名的很难做好，这同样适用于测试。关于如何命名测试有几种流行的约定。无论你使用哪一种都没有关系，只要你能够一贯使用，并准确描述正在测试什么。

6、让测试做太多事情

又长又复杂的名字通常说明了你想同时测试多件事情。单个测试应该只测试一件事情。如果失败了也应该在代码中注明是什么地方出了错。你没有必要为了知道代码中出了什么问题而查看是哪部分测试失败。这并不意味着你不应该在测试中有多个断言，但这些断言应该紧密相关。例如，一个查看订单处理系统输出，并确认输出中是否有一个单一项目以及它是否包含具体项目的测试，是ok的。但一个验证相同系统的输出的测试，既创建一个特定项目，又记录到数据库中，还发送确认电子邮件，就不行了。