Django unittest只读测试数据库

时间:2022-09-11 18:21:37

I must be missing the obvious here. I am using django 1.5.x and am creating unittests, based on djangos TestCase class. I have a bunch of DBs defined in settings as i am pulling (read-only) from alot of different source. When running test i only want to create a test version of my default db the rest i want to flag as read-only and not try to recreate as test_db_name (the user defined won't (can't) have the permissions to create these dbs anyway).

我必须在这里忽略这一点。我正在使用django 1.5.x并且正在创建基于djangos TestCase类的单元测试。我在设置中定义了一堆数据库,因为我从很多不同的源中提取(只读)。运行测试时我只想创建我的默认数据库的测试版本,其余我想要标记为只读而不尝试重新创建为test_db_name(用户定义的不会(不能)拥有创建这些权限的权限无论如何dbs)。

Surely this is possible - as i say i must be missing the obvious?

当然这是可能的 - 正如我所说,我必须错过显而易见的事情?

Grateful for any help.

感谢任何帮助。

Mathew

2 个解决方案

#1


1  

Not obvious, no. Sort-of documented, you can set the database name to use whilst testing:

不明显,不。记录的排序,您可以设置在测试时使用的数据库名称:

settings.py

DATABASES = {
  'default': {
    'ENGINE': 'django.contrib.gis.db.backends.spatialite',
    'NAME': 'db.sqlite3',
    'TEST_NAME': '/tmp/test.sqlite3',
  },
}

If you want to then not build (or rebuild) the test database, you'll need to duplicate the database name into TEST_NAME and use the new python manage.py test --keepdb command to leave the database intact, rather than having Django try to delete it between runs. As of June 2014 you have to upgrade to the development version of Django to access this; eventually this will be in the stable release. The downside of this is, as I understand it, it applies to all databases, not just your read-only ones.

如果您不想构建(或重建)测试数据库,则需要将数据库名称复制到TEST_NAME并使用新的python manage.py test --keepdb命令保持数据库完整,而不是让Django尝试在运行之间删除它。截至2014年6月,您必须升级到Django的开发版才能访问它;最终这将是稳定发布。这方面的缺点是,据我所知,它适用于所有数据库,而不仅仅是您的只读数据库。

#2


0  

I had the same problem and managed to solve it like this:

我遇到了同样的问题并设法解决了这个问题:

settings.py

DATABASES = {
    'default': {...},
    'other': {...}
}

DATABASE_ROUTERS = ['routers.MyRouter']

...

TESTING = 'test' in sys.argv

if TESTING:
    DATABASE_ROUTERS = []
    DATABASES.pop('other')    

If you don't use hard coded db routing such as with 'using' and only use the 'DATABASE_ROUTERS', then this solution should be good enough for you.

如果您不使用硬编码数据库路由,例如使用'使用'并且仅使用'DATABASE_ROUTERS',那么此解决方案应该足够好。

Of course, if you want to actually test the connection to the remote DB and the data stored there then this would not be the way to go.

当然,如果您想要实际测试与远程数据库的连接以及存储在那里的数据,那么这将不是可行的方法。

#1


1  

Not obvious, no. Sort-of documented, you can set the database name to use whilst testing:

不明显,不。记录的排序,您可以设置在测试时使用的数据库名称:

settings.py

DATABASES = {
  'default': {
    'ENGINE': 'django.contrib.gis.db.backends.spatialite',
    'NAME': 'db.sqlite3',
    'TEST_NAME': '/tmp/test.sqlite3',
  },
}

If you want to then not build (or rebuild) the test database, you'll need to duplicate the database name into TEST_NAME and use the new python manage.py test --keepdb command to leave the database intact, rather than having Django try to delete it between runs. As of June 2014 you have to upgrade to the development version of Django to access this; eventually this will be in the stable release. The downside of this is, as I understand it, it applies to all databases, not just your read-only ones.

如果您不想构建(或重建)测试数据库,则需要将数据库名称复制到TEST_NAME并使用新的python manage.py test --keepdb命令保持数据库完整,而不是让Django尝试在运行之间删除它。截至2014年6月,您必须升级到Django的开发版才能访问它;最终这将是稳定发布。这方面的缺点是,据我所知,它适用于所有数据库,而不仅仅是您的只读数据库。

#2


0  

I had the same problem and managed to solve it like this:

我遇到了同样的问题并设法解决了这个问题:

settings.py

DATABASES = {
    'default': {...},
    'other': {...}
}

DATABASE_ROUTERS = ['routers.MyRouter']

...

TESTING = 'test' in sys.argv

if TESTING:
    DATABASE_ROUTERS = []
    DATABASES.pop('other')    

If you don't use hard coded db routing such as with 'using' and only use the 'DATABASE_ROUTERS', then this solution should be good enough for you.

如果您不使用硬编码数据库路由,例如使用'使用'并且仅使用'DATABASE_ROUTERS',那么此解决方案应该足够好。

Of course, if you want to actually test the connection to the remote DB and the data stored there then this would not be the way to go.

当然,如果您想要实际测试与远程数据库的连接以及存储在那里的数据,那么这将不是可行的方法。