构建之法阅读笔记01
——单元测试
一转眼，大三下学期开设软件工程这门课已经一个月左右了。上课时老师会给我们按照邹欣老师的《构建之法》来给我们讲述软件开发的流程、培养我们软件工程师应该具备的素质。刚开学的时候有发表过浅读这本《构建之法》所不能理解的几个问题，在学*了将*一个月这本书之后，我对于一些问题有了新的认识。
回想第二章讲述“个人技术和流程”的时候老师讲到了“单元测试”，这个问题起初并没有引起我多少的注意，说实话开始时也只是为了完成王老师撰写单元测试博客而去编写单元测试部分的代码，在任务越来越难任务量越来越大的现在，我充分认识到这个问题的重要性。
单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。单元测试应该测试程序中最基本的单元——如在C++/C#/Java中的类，在此基础上，可以测试一些系统中最基本的功能点（这些功能点由几个基本的类组成）。从面向对象的设计原理出发，系统中最基本的功能点也应该由一个类及其方法来表现。单元测试要测试API中的每一个方法及每一个参数。单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。
我们自上大学以来也或多或少学过不少的编程语言：C++、C#、JAVA、PHP……当然，也编写过很多的程序，小到计算两个数的最大公约数、计算闰年、分段函数求值等，大到小学期课程设计大作业猜数字游戏、遍历校园最短路线图甚至是连接数据库的小型系统等等。但是我们为了能够尽快上交作业或者说是为了达到老师的要求编写很长的代码项目的时候有几个人会真正考虑到代码的可用性，有没有BUG之类的问题呢？甚至有的时候即使是很长的包含很多函数的项目代码，我都会是有一点思路就会开始编写，从不会考虑执行效益等的问题，就总是觉得我写出来了就很不错了。然后在主函数写完之后运行出现错误，就会急着去找学的好的同学或老师给改。慢慢养成了心浮气躁的坏毛病不说，修改代码的工作量也会大大增加。
这学期来老师布置的有关“二柱子四则运算”的迭代问题中，（其实最开始也是为了应付老师……），我不得每写完一个函数（即使是返回一个数的绝对值这样“简单”的函数）就去比编写单元测试的代码去测试函数的返回值、可用性是否合理等。这样做我们可以避免繁重的代码编写完之后，运行出好几百个错误，我们看着就心烦然后还要逐行去排查，最后可能发现错误之处仅仅是因为括号没有对应好甚至是用汉语编写了分号等。而且最重要的有的时候我们不能确定某一个函数或者某一个语句代码使用之后会产生怎样的结果，所以我们必须编写单元测试去验证正确之后才可以放置到自己的项目中。慢慢的，我发现这样编写项目很开心，把一整个大的项目分成了很多个函数，可以在零碎的时间编写某一个函数，而且最后所有函数完成之日就离我们的成功不远啦！！
通过学*《构建之法》我相信我可以慢慢在更多的项目工程中养成主动去编写单元测试的好*惯！！<(￣ˇ￣)/
