代码测试时犯的10个错误

1没有测试

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

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

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

3缩写失败的测试

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

4担心未实现测试

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

5没有很好的命名测试

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

6让测试做太多事情

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

7没有实际测试代码

经常可以看到测试新手创建过于复杂的模型以及不能实际测试代码的设置程序，他们可能会验证模型代码是佛正确，或者模型代码是否和真正代码做相同的事情，或没有任何断言只是执行代码。这样的“测试”就是白费力气，特别是如果他们的存在只是为了提高代码覆盖率水平的话。

8担心代码覆盖率

代码覆盖率的理念很崇高，但往往实际价值有限，知道运行测试的时候有多少代码被执行应该是有用的，但因为它并不考虑正在执行代码的测试质量，因此就变得没有意义，代码覆盖率在它数值非常高或非常低的时候，是挺诱人眼球的。如果非常高，就表明，比起带来的价值，过多的代码可能正在被测试。非常低的代码覆盖率表明有可能代码的测试不够，因为这样模棱两可的意思，有的人就不知道单一片段的代码是否应该进行测试。

9着眼于一种类型的测试

一旦开始测试。很容易只纠结于一种风格的测试，这是一个错误，只用一种类型的测试，就不能长沙市系统的所有部分，需要单元测试来确认代码的各个组件是否能正常工作，你需要集成测试来确认不同组件是否能协同工作，你需要自动化测试来验证软件是否可以如预期试用。

10着眼于短期测试

来自测试的价值大多数会随着时间的推移而获得，测试不应该只存在用于确认事情是否正确写入，而应该随着时间的推移继续起作用，并且对于代码库做其他的改变。有回归错误或新的异常，那么测试应该重复运行以尽早发现问题，这就意味着错误或异常可以更快，更便宜和更容易被修复。没有变化可自动和快速执行测试，是什么编码测试如此有价值的原因。

大开科技近日在腾讯课堂推出关于Python语言学习的免费课程，今后还会陆续完善其他方面的系列课程，使网络教学的课程体系更加完善、系统。