如何使 django 测试框架从实时数据库读取?

发布于 2024-09-05 03:26:55 字数 431 浏览 11 评论 0原文

我意识到这里有一个类似的问题,但这个问题有不同的方法:我有一个 django 应用程序,它对使用 djapian;我想为此应用程序的搜索组件编写单元测试,显然,我需要 django 设置模块以及与活动数据库的所有连接,因此 django 提供的测试运行程序似乎很理想。 但是,django 测试框架创建了一个虚拟数据库,我不想将所有数据转储到固定装置中,然后对其进行索引(测试将永远花费 !);

我的数据没有风险,因为测试只会从数据库读取,那么,如何实现这一点呢? -我对整个单元测试很陌生,所以我在类似的问题中读到的编写新的测试运行程序的解决方案并没有给我一点启发,至少没有一些细节

I realize there's a similar question here, but this one has a different approach: I have a django app that does queries over data indexed with djapian ; I'd like to write unit tests for this app's search component, and, obviously, I'd need the django settings module and all connections with the database active, so the test runner that django provides seems ideal. however, the django testing framework creates a dummy database and I'd hate to dump all my data to a fixture and then index it (the tests would take forever!);

My data isn't at risk because the tests would only read from the database, so, how could this be achieved? -I'm new at this whole unit testing thing, so the solution of writing a new test runner I read in that similar question doesn't enlighten me a bit, at least not without some details

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

数理化全能战士 2024-09-12 03:26:55

阅读 djapian 的测试用例,我发现了一些非常有趣的东西:这些人所做的是使用 TestCase 类的 setUp 方法:他们创建一个对象,然后使用索引器的 update 方法,因此他们实际上有一个文档来搜索 < em>以及一种编写受控查询测试的方法!
对于好奇的人来说,该方法看起来像这样:

def setUp(self):
    p = Person.objects.create(name="Alex")

    for i in range(self.num_entries):
        Entry.objects.create(author=p, title="Entry with number %s" % i, text="foobar " * i)

    Entry.indexer.update()

我认为这可以,但我们必须记住我正在这里测试一个小搜索引擎,所以这个解决方案可能是简单的出路;不过,我无法提出反对意见,所以如果你们有一个答案可以帮助定义一个在 python 中测试此类 webApp 的策略,那么我们非常欢迎!

-我想我现在会解决这样的问题(我也想用完全填充的数据库来测试查询的延迟,但我想我可以稍后在 Funkload)

编辑:好的,为了忠实于任何感兴趣的人的解决方案,我遇到了另一个问题:xapian索引(如评论中所述)。为了解决这个问题,我创建了一个默认测试运行程序,将生产 xapian 索引更改为测试索引(较小的索引,使用管理脚本创建)。这个运行程序相当简单:

def custom_run_tests(test_labels, verbosity=1, interactive=True, extra_tests=[]):
    """Set the test indices"""
    settings.CATEGORY_CLASSIFIER_DATA = settings.TEST_CLASSIFIER_DATA    
    return run_tests(test_labels, verbosity, interactive, extra_tests)

并且,要使用它,我只需添加一个设置:

TEST_RUNNER = 'search.tests.custom_run_tests'

出于性能和可读性原因,我放弃了上述方法(在设置中创建文档):为了测试数据库,我需要相当数量的文档,其中包含一些文本(一两个段落),所以我最终为此创建了一个固定装置(我使用了一个管理命令在真实数据库中创建文档,将它们序列化 - 将它们写入文件 - 然后删除它们)。
所以,最后,我根本没有从实时数据库中读取数据,而是使用了用有点 hacky 的脚本和自定义运行器创建的测试装置,这并不难:)

Reading the test cases for djapian I found something really interesting: what those guys do is use the setUp method for the TestCase class: they create an object and then use the update method for the indexer, so they effectively have a document to search for and a way to write controlled query tests!
For the curious, the method looks something like this:

def setUp(self):
    p = Person.objects.create(name="Alex")

    for i in range(self.num_entries):
        Entry.objects.create(author=p, title="Entry with number %s" % i, text="foobar " * i)

    Entry.indexer.update()

I think this would do, but we have to remember I'm testing a little search engine here, so this solution might be the easy way out; I can't come up with an objection, though, so if you guys have an answer that'll help define a strategy for testing this kind of webApps in python in general, it's more than welcome!

-I think I'll settle for something like this for now (I wanted to test the latency of the queries with a fully populated database also, but I think I could do that later with bench tests in Funkload)

EDIT: Ok, to be faithful to a solution for anyone interested, I ran into another issue: the xapian index (as stated in the comment). To solve it, I created a default test runner that changed the production xapian index for a test index (a smaller one, created with a management script). This runner is fairly simple:

def custom_run_tests(test_labels, verbosity=1, interactive=True, extra_tests=[]):
    """Set the test indices"""
    settings.CATEGORY_CLASSIFIER_DATA = settings.TEST_CLASSIFIER_DATA    
    return run_tests(test_labels, verbosity, interactive, extra_tests)

And, to use it, I simply added a setting:

TEST_RUNNER = 'search.tests.custom_run_tests'

I dropped the aforementioned approach (creating the documents in the setUp) for performance and readability reasons: to test the database I needed a decent amount of documents with some text (a paragraph or two), so I ended up creating a fixture for that (I used a management command that created the documents in the real database, serialized them -writing them to a file- and then deleted 'em).
So, in the end, I didn't read from the live db at all and instead used test fixtures created with a somewhat hacky script and a custom runner, and it wasn't that hard :)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文