什么是单元测试？
如果你听过“测试驱动开发”（TDD:test-Driven Development），单元测试就不陌生了。
单元测试简单来说就是对某个函数或者API进行正确性验证。
比如对于函数abs(),我们可以编写以下几个测试用例：
- 输入正数，期待返回值与输入相同。
- 输入负数，期待返回值与输入相反。
- 输入0，期待返回0。
- 输入非数值类型，期待抛出typeError。
把上面的测试用例放到一个测试模块里，就是一个完整的单元测试。
如果单元测试通过，说明我们测试的这个函数能够正常工作，如果单元测试不通过，要么函数有bug，要么测试条件输入不正确，需要修复使单元测试能够通过。
单元测试的意义
单元测试通过后有什么意义吗？
如果我们对abs()函数代码进行了修改，只需要再跑一次单元测试。如果通过，说明我们的修改不会对abs()函数原有的行为造成影响，如果测试不通过，说明我们的测试与原有行为不一致，要么修改代码，要么修改测试用例。
这种以测试为驱动的开发模式最大的好处就是确保了一个程序模式的行为符合我们设计的测试用例，在后期修改时，能够极大程度地保证该模块行为任然是正确的。
当一个项目由多个人维护的时候，假如A写了一个页面，B去维护A的页面加了一些逻辑，C去维护该页面再添加一些逻辑，当A再去维护这个页面的时候，可能已经不认识他曾经写的代码了，函数也不是原来的语义了，大部分的变量都不知道是干什么用的。那么A需要捋清楚B、C的逻辑，在B、C的基础上再小心翼翼的编写新的需求，生怕哪一步写错，导致线上的代码出错。长此以往下去，代码变得越来越难维护，越来越少的人能看懂页面内的逻辑，糊墙式代码将页面堵得水泄不通！当然这是最坏的想法。
所以依赖我们自觉去维护代码，首先对我们个人能力有很高的要求，其次对我们的精力也很浪费。我们要时刻注意自己的代码是否会影响到别人的代码。从长远考虑，单元测试是一个大型项目的必然选择。
