单元测试对代码质量的影响
1.（过去的做法）
记得大一大二写程序的时候，从来都不写单元测试，现在去分析当时的心理，可能出于三个原因。第一，当时写代码的水平非常low，当然现在也挺low的，不过现在是大三了，更何况在上《软件工程》，编写代码的水平较以前肯定会有很大的提高。大一大二的时候，可能当时老师布置下任务以后，等到老师检查的时候差不多才刚刚把任务完成，来不及写单元测试就需要向老师展示结果了，这是第一个原因。第二个原因则是不敢写单元测试，以前写程序的时候往往用一组特殊的数据去验证程序的正确性，只要这组数据能让程序得到正确的结果，那就代表自己写的这个程序过关了，从未想过多用几组数据去测试一下，也不敢用别的数据去测试，因为一换数据就有可能导致程序出错，正是这种害怕程序出错的心理，让我的编程水平在很长的一段时间内都处于一个停滞不前的状态。第三个原因则是不会写单元测试，过去老师对我们的要求就是能实现程序应有的功能，所谓的测试也就只是多用几组数据去测试一下程序的结果，从来不会单独的写一个小程序从多方面的角度去验证程序。
因此，真正学习了单元测试并在实际的编程中使用单元测试时，才发现，单元测试是保证代码质量的有效手段。所谓的单元测试其实就是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。执行单元测试，是为了证明某段代码的行为确实和开发者所期望的一致，使用单元测试这个简单有效的技术就是为了令代码变得更加完美。除了我上述所说的三个原因外，编程者不喜欢写单元测试还有很多的“理由”：编写单元测试太花时间了、运行测试的时间太长了、我并不清楚代码的行为，所以也就无从测试、这些代码都能够编译通过等等。其实这些理由都是一些借口，当我们真正走向工作岗位以后，写单元测试是必不可少的工作，其实写好单元测试可以有效的提高代码的质量，在对工程整合时，模块代码的质量才不会在整个工程中有太大的问题。
2.（不写单元测试的坏处）
就普通的程序员来讲，平均每十行代码就会存在一个Bug，这也就意味着程序员在编程序时存在Bug是在所难免的。写单元测试就是对一个小模块或者一个小功能的测试，这个小模块在写之前我们就明确了它要完成什么功能，因此单元测试就是一个提前找Bug的过程。在实际的工作中，一个个的大工程都是由不同的编程人员编写一个个小的模块或者小的功能，最终将这些模块整合到一起，形成一个完整的项目。如果在编写完一个较小的模块后不写单元测试，可能这一个小的模块在单独运行时功能实现比较好，但是当将其整合到整个工程中时就有可能出现大量的Bug，这些Bug出现的原因有很多种，可能是某种条件没有考虑进去导致了功能的缺陷，也有可能是与别的模块存在冲突等等。总之，不写单元测试，程序的质量就没法得到很好的保障。
3.（改进的办法）
对于程序模块写单元测试时，常用的方法有Right-BICEP原则。Right-BICEP原则其实是对程序测试时比较重要的6个部位，第一个单词Right，是指要用多组数据去测试程序能否得到正确的结果，第二个字母B是指程序所有的边界条件是否都能够得到正确的处理，第三个字母I是指能否检查程序的反向关联，第四个字母C是指程序在交叉检查时是否仍然能够得到正确结果，第五个字母E是指能否强制程序错误条件的发生，最后一个字母P则是指程序是否满足了功能的需求。Right-BICEP测试原则是当下比较常用的测试方法，而且通过这6个方面的测试，程序的质量一般可以得到很好的保障，即使在对程序进行整合时仍有Bug存在，但是那时解决Bug也是比较容易的。
从我们学生的角度讲，虽然现在没有公司的硬性规章制度在约束着我们，但是我们应该培养起写单元测试的好习惯，写单元测试一方面是为了得到高质量的代码，另外，它可以锻炼我们考虑问题的能力，在查找Bug修改Bug的过程中，我们可以把问题考虑的更加全面。除了要写单元测试外，我们还要对单元测试的结果进行记录统计，因为每个程序员由于自身编程习惯的不同，很多时候会犯相同的错误，通过对单元测试的结果进行记录，我们可以统计出自己常犯的一些错误，在后期的编程中加以有目的的关注，我们便可以提高编程的效率和质量。
来源：https://www.cnblogs.com/hulidanxiang/p/5528028.html