加快Django测试 [英] Speeding up Django Testing

查看:110
本文介绍了加快Django测试的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我想通过Django了解更多有关测试流程的信息。



背景信息
http://docs.djangoproject.com/en/dev/topics/testing/



使用测试驱动开发时遇到困难。
Django的测试运行器在启动时不断创建测试数据库中的所有数据库模型。
对于我们当前的项目(40到240个模型),这意味着需要20秒才能开始测试。



这使得它完全不能用于测试新的功能经常。
我的问题,你们如何解决这个问题?



过去我已经尝试了一些东西
a。) - 更改testloader每次重用相同的测试db,并在需要时应用迁移
b。) - 从 __ main __ python文件流中运行我的单元测试



选项b与sys.path尴尬,选项a可行,但似乎不是django方式。



更新:
选项A确实不是一个坏的解决方案。它只是相当多的努力。这使我相信人们使用不同的解决方法。 SQL Lite可能是这种解决方法。但是我猜测还有更多的。

解决方案


更改testloader每次重用同一个测试数据库并在需要时应用迁移





  1. 我在编写自己的测试时看不到任何错误运行者只是截断表而不是删除和创建数据库。这是djangoic,因为它解决了一个具体的问题。打开允许将测试用例分组到测试套件中的 ticket 。一旦修复,您应该可以将您的测试用例组合成套件以便于管理。您还可以检查附加到票的补丁,看看是否符合您的目的。


  2. 由于内部建议您可以使用内存数据库。这在很大程度上取决于您的数据模型和可跨数据库移动的查询。


  3. 如果您还没有尝试重新组织测试用例。在我的经验中,并非所有测试类都需要分类 django.test.TestCase 。找出可以通过分类 unittest.TestCase 的测试类。这将加快一点点的位置。


  4. 重组灯具。将常见的夹具移动到单个文件,并在测试运行之前加载它,而不是在每个测试类中(使用 fixtures = [...] )。



Im looking to learn more about your testing flows with Django.

Background information http://docs.djangoproject.com/en/dev/topics/testing/

Im encountering difficulties when using test driven development. The test runner of Django constantly creates all db models in a test db when starting. For our current projects (between 40 and 240 models) this means it takes easily 20s for tests to start.

This makes it completely unworkable for testing a new feature often. My question, how do you guys work around this?

I've tried a few things in the past a.) - change the testloader to reuse the same test db every time and apply migrations when needed b.) - run my unit tests from within the __main__ flow of python files

option b is awkward with the sys.path, option a is doable but doesnt seem to be the django way.

Update: Option A is indeed not such a bad solution. Its just quite a bit of effort. Which makes me believe people use a different workaround. SQL lite could be that workaround. But im guessing there are more.

解决方案

change the testloader to reuse the same test db every time and apply migrations when needed

  1. I don't see anything wrong in writing your own test runner that merely truncates the tables instead of dropping and creating the database. This is djangoic in that it solves a specific problem. There is a ticket open for allowing grouping of test cases into test suites. Once it is fixed you should be able to group your test cases into suites for easier management. You can also inspect the patch attached to the ticket and see if it will suit your purpose.

  2. As Ned suggested you can use an in memory database. This depends to a large extent on your data model and queries being portable across databases.

  3. If you haven't already try to reorganize your test cases. In my experience not all test classes need to sub class django.test.TestCase. Find out those test classes that can do with sub classing unittest.TestCase. This will speed up things a little bit.

  4. Reorganize fixtures. Move common fixtures to a single file and load it before the test run rather than inside each test class (using fixtures = [...]).

这篇关于加快Django测试的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆