在Django中对FileField进行单元测试的干净方法是什么? [英] What is the clean way to unittest FileField in django?

查看:105
本文介绍了在Django中对FileField进行单元测试的干净方法是什么?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个带有FileField的模型.我想对它进行单元测试. django测试框架具有管理数据库和电子邮件的绝佳方法. FileFields有类似的东西吗?

如何确保单元测试不会污染真实的应用程序?

预先感谢

PS:我的问题几乎是使用测试装置进行Django测试FileField的重复,但没有可接受的答案.只想重新询问一下有关此主题的新知识.

解决方案

有几种方法可以解决此问题,但是它们都很丑陋,因为应该将单元测试隔离开来,但是文件都是关于持久更改的.

我的单元测试不在具有生产数据的系统上运行,因此每次运行后都可以使用git reset --hard之类的方法简单地重置上载目录,这很容易.在某些方面,这种方法是最好的,因为它不涉及任何代码更改,而且只要您从良好的测试数据开始就可以保证这种方法可以正常工作.

如果在测试模型的保存方法后实际上不需要对该文件执行任何操作,则建议使用python出色的的东西),因此您可以完全避免更改文件处理逻辑. Mock库有两种方法全局修补在测试方法中,Django的文件类就像这样简单会得到的.

如果您需要一个真实的文件(例如,作为测试的一部分,使用外部脚本进行处理等),则可以使用类似于Mirko的示例的内容,并创建一个临时文件模块的mkdtemp函数).只要您有一个类似的STATIC_ROOT之类的东西,并将其用作源代码中的媒体文件,此方法就可以正常工作.

  • 使用自定义存储管理器
  • 在每个File实例上手动设置文件路径,或具有自定义的 Michael Foord的版本

    I have a model with a FileField. I want to unittest it. django test framework has great ways to manage database and emails. Is there something similar for FileFields?

    How can I make sure that the unittests are not going to pollute the real application?

    Thanks in advance

    PS: My question is almost a duplicate of Django test FileField using test fixtures but it doesn't have an accepted answer. Just want to re-ask if something new on this topic.

    解决方案

    There are several ways you could tackle this but they're all ugly since unit tests are supposed to be isolated but files are all about durable changes.

    My unit tests don't run on a system with production data so it's been easy to simply reset the upload directory after each run with something like git reset --hard. This approach is in some ways the best simply because it involves no code changes and is guaranteed to work as long as you start with good test data.

    If you don't actually need to do anything with that file after testing your model's save method, I'd recommend using python's excellent Mock library to completely fake the File instance (i.e. something like mock_file = Mock(spec=django.core.files.File); mock_file.read.return_value = "fake file contents") so you can completely avoid changes to your file handling logic. The Mock library has a couple of ways to globally patch Django's File class within a test method which is about as easy as this will get.

    If you need to have a real file (i.e. for serving as part of a test, processing with an external script, etc.) you can use something similar to Mirko's example and create a File object after making sure it'll be stored somewhere appropriate - here are three ways to do that:

    • Have your test settings.MEDIA_ROOT point to a temporary directory (see the Python tempfile module's mkdtemp function). This works fine as long as you have something like a separate STATIC_ROOT which you use for the media files which are part of your source code.
    • Use a custom storage manager
    • Set the file path manually on each File instance or have a custom upload_to function to point somewhere which your test setup/teardown process purges such as a test subdirectory under MEDIA_ROOT.

    Edit: mock object library is new in python version 3.3. For older python versions check Michael Foord's version

    这篇关于在Django中对FileField进行单元测试的干净方法是什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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