Django Testing

Django 自己的 unittest 支持的挺好，一般只需要在 app 下面加一个 tests.py 在里面写 case 就可以了。case 对应的类继承 django.test.TestCase 就好。

每一个测试类里面，都可以有一个 setUp 方法，是在 case 方法执行前执行，例如一些准备工作，和一个 tearDown 方法，在 case 执行之后执行，例如一些清理工作。还可以有若干个使用 test 开头的测试用例。

case 我觉得一般可以分两种，方法测试，和接口测试。

方法测试指针对一些 工具 方法什么的测试，当然这个说法并不严谨，将就理解吧。我把这些归类为不涉及到数据库操作的测试。

接口测试，一般会涉及到数据库操作，需要验证登录啊，参数什么的。

Django 里面，每个测试用例之间是通过事务互相隔离的，所以不用担心互相之间会有影响。

接口测试可以通过 django.test.Client 来访问你的接口，然后比对返回结果，或者比对数据库的数据来验证。

有时候一些接口是依赖已有数据的，比如一个返回所有用户的接口，那测试的时候数据库是需要有用户才能返回的。这个可以通过 fixture 来 moke 数据。

fixture 就是一些 json 文件，里面放的是和 model 的数据，这样一个测试如果需要某几个 model 对应的表里面事先有数据，那可以把他们放到 fixture 文件里面，让 django 在运行之前先 load 到数据库就可以了。

这些 json 文件自己编写会死，Django 提供了 manage.py dumpdata --indent 4 [app_label[.ModelName] [app_label[.ModelName] 功能，可以方便你导出数据库里面已有的数据。不指定 app_label 和 modelname 就会导出全部的，一般只导出自己需要的就好。注意 json 文件是可以支持缩进的。

如果从比如开发库之类的倒数据，会觉得数据有点乱，从测试库倒数据似乎比较清净，因为每次测试都是一个空的数据库。有一个方法是在测试用例里面创建依赖的数据，但是测试执行完了再执行 manage.py dumpdata 已经什么数据都没有了。这个时候可以在测试用例里面使用 django.core.management.call_command 来执行 dump，例如

call_command(
    'dumpdata',
    '--indent', '4',
    'app_label', 'ModelName',
    'app_label', 'ModelName'
)

命令行执行测试的时候，会打印出来 dump 出来的数据，把他们存到一个 json 文件然后引入就可以了。

有一个提升测试速度的方法，是使用 -k 参数，这个参数会保留测试的数据库，不会每次都删除重建，这样节省一些时间。

还可以使用 --parallel N 参数来增加并行数量。如果你用 coverage 那整个命令是类似这样的 coverage run --parallel-mode --concurrency=multiprocessing manage.py test -k --parallel 3 。使用并行之后，会发现 coverage 不工作了，这是因为并行的时候，每个线程都会单独写一个 coverage 结果文件，所以执行 coverage report 之前，执行一下 coverage combine 合并到一个文件就可以了。

Django 还是做的挺不错的。测试这么方便，实际很适合使用 TDD 方式开发。