By

Contents
  1. 1. forward
  2. 2. unittest
    1. 2.1. 测试原理
    2. 2.2. 关于覆盖率
    3. 2.3. 先功能，还是先测试？
  3. 3. others

科普向

forward

单元测试的好处与必要性我就不多说了，以现在做的ec_forum项目为例，说说现在我所做的。

unittest

测试原理

我使用的单元测试模块是python原生的unittest，其实用什么的模块并不重要，反正都是无尽的assert，它的结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
import unittest
class ECTestCase(unittest.TestCase):
	def setUp(self):
		print(1)
	def tearDown(self):
		print(2)
	def test_name1(self):
		print(3)
	def test_name2(self):
		print(4)
	def name3_test(self):
		print(5)
		
if __name__ == '__main__':
    unittest.main()

然后我们看输出

1
2
3
4
5
6
7
8
9
10
11
1
3
2
.1
4
2
.
----------------------------------------------------------------------
Ran 2 tests in 0.000s
OK

可以看出，在进行每一项测试时，ECTestCase类会找到test开头的方法，在执行时会执行一次setUp，执行结束时执行一次tearDown，执行完成后输出一个.，执行完所有方法为止。如果中途报错即立刻停止测试。别忘记到数据库里去删测试账号。

一般setUp和tearDown方法里，我一般是注册与销毁n个随机信息的账号，发表和删除同一篇文章，并用这些账号测试。这里的测试是单线程的，所以不用担心self属性被多线篡改的问题。这两个方法里尽量少放东西，这样后期测试多了以后速度影响会比较大，我只是把生成两篇文章改成了把其中一篇不太用的文章移到了其中一个测试里，测试速度就从1.7s提升到了0.9s。

关于覆盖率

能够触及到代码的每一个角落当然是最吼的（100%），不过这样改起来的东西也多，因此我们在assert的时候尽量用巧妙的方法。比如code_information修改频繁的话，那就去比对状态码，如果状态码修改频繁的话，就去比对message，甚至是返回值的数据类型，数组、字符串长度范围等。测试覆盖率越高，后期可见或不可见的坑就越少。

记得在提交版本的时候，先做一次make test，从而尽量避免提交bug版本。

先功能，还是先测试？

如果需求炒鸡明确的话，建议测试先行，一定程度上先测试能起到规范功能的作用，某种意义上比文档作用更大。

如果需求是在变化的话，走一步看一步的那种，实际上单元测试也不是必要的，或者想我这种只有一个人的话，那就随意。脚本测试也够用了（比如注册机）

others

不为测试而写测试，我最初更向是一种『哦？！这就是单元测试啊！』的感觉，在开发路程中实际感觉到需要这么一种东西来确保我的真实进度，然后从简单的脚本测试到单元测试，感觉很自然的就过度过去了。

Contents
  1. 1. forward
  2. 2. unittest
    1. 2.1. 测试原理
    2. 2.2. 关于覆盖率
    3. 2.3. 先功能，还是先测试？
  3. 3. others