使用其他测试框架-clough-dynamics of structures

12.6测试数据库需要数据库的测试（即模型测试）不会使用生产数据库，Django会为测试单独创建空数据库。不管测试通过还是失败，测试数据库都在全部测试执行完毕后销毁。如果不想销毁测试数据库，运行test命令时指定-- keepdb旗标。这样，在两次运行测试之间测试数据库会留存下来。如果测试数据库不存在，首先新建。为了保证模式最新，还会运行迁移。默认情况下，测试数据库的名称是在DATABASES设置中的NAME选项前加test_。如果使用SQLite数据库引擎，测试默认使用内存中的数据库（即，数据库在内存中创建，完全不用文件系统）。如果想使用其他数据库名称，在TEST设置中为DATABASES设置列出的各个数据库指定NAME选项。使用Post- greSQL时，USER还要有内置postgres数据库的读权限。对同一个数据库来说，测试运行程序始终使用设置文件中的数据库设置：ENGINE、USER、HOST，等等。测试数据库由USER指定的用户创建，因此要确保指定的用户有足够的权限在系统中新建数据库。 12.7使用其他测试框架显然，unittest不是唯一的Python测试框架。虽然Django不直接支持其他测试框架，但是却为调用其他框架编写的测试提供了方式，让Django认为那就是普通的Django测试。执行./manage.py test命令时，Django根据TEST_RUNNER设置决定接下来做什么。TEST_RUNNER默认指向django.test.runner.DiscoverRunner。这个类定义Django默认的测试行为，包括： 1.执行全局的测试前准备工作。 2.在当前目录中查找名称匹配test*.py模式的测试文件。 3.创建测试数据库。 4.运行迁移，把模型和初始数据填充到测试数据库中。 5.运行找到的测试。 6.销毁测试数据库。 7.执行全局的测试后清理工作。如果你自己定义了测试运行程序类，而且把TEST_RUNNER指向它，每次执行./manage.py test命令时，Djan- go都会使用那个测试运行程序。如此以来便可以使用任何Python测试框架，或者调整Django执行测试的过程，满足特定的需求。关于这个话题的详细说明，参见Django Project网站。 12.8接下来现在你知道如何为自己的Django项目编写测试了，下面我们换个重要话题，讨论如何把项目变成真正的线上网站，即把Django项目部署到Web服务器上。 190 -第12章测试Django应用程序