使用配置文件进行测试
我的 Google-fu 给了我我不明白的结果,让我失望了,所以我在这里问。
我正在开发一个 Python 项目,目前有一个配置文件,也是 .py,它包含在一切启动时加载的各种 python 对象。我正在尝试使用 pytest 进行一些练习单元测试,但我不知道如何解决这个问题。我的猜测是,我可能会制作一个不会更改的专用测试配置文件,但我不知道如何告诉我的代码何时使用实际配置文件以及何时使用测试配置文件。我的代码中当前的设置只是使用 import config
并从中设置值。我非常感谢这里的一些帮助!
my Google-fu has failed me by giving me results I don't understand, so I'm asking here.
I'm working on a Python project and I currently have a configuration file, which is also .py, that holds various python objects to load when everything starts. I'm trying to get some practice unit testing with pytest and I don't know exactly how to go about this issue. My guess is that I am probably going to make a dedicated testing config file that doesn't change, but I have no clue how to tell my code when to use the actual config file and when to use the testing config file. My current setup in my code is just using import config
and setting values from it. I would greatly appreciate some help here!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我用来解决此问题的方法是在运行测试时操纵路径,以便附加包 (/tests/resources) 可以隐藏我为包含配置等资产而设置的普通资源包 (/main/resources)文件并使其可在运行时加载。
注意:这个结构的灵感来自于我从 Java/Maven 带来的模式,所以我不会声称它是 Pythonic,而且我不喜欢测试所涉及的路径操作(我知道很多)其他人也不会,所以要小心!)。事实上,我在寻找更好的方法时发现了这个问题。
要实现此目的,您首先必须设置一个文件夹作为“资源”包(请参阅 文档)。完成后,您可以在测试文件夹中为测试创建类似的版本。目录结构将如下所示:
请注意,main 和tests 不是包。这与 Python 项目结构中的许多传统指导相矛盾。相反,它们都被添加到路径中,并通过 run_tests.py 脚本使用这样的代码将测试插入到 main 前面的路径中(一些位借自 这篇文章:
我通常会有其他选项要提供给 pytest,这就是
args
是因为,但它与这个答案无关,所以我在这里留空,我知道这是一个迟到的答案,但我希望这对某人有帮助。另外,我知道这是一个有争议的方法,但这是我最满意的方法。到目前为止发现,这可能是因为我在 Java 和 Python 方面都有经验,对于其他人来说,尝试导入tests.resources 并在失败时导入 main.resources 的方法可能是更好的方法
。对此的方法将分享发表评论,或发布其他答案。
An approach I've used to solve this problem is manipulating the path when running tests so that an additional package (/tests/resources) can shadow the normal resources package (/main/resources) that I set up for containing assets such as configuration files and making them available for loading at runtime.
Note: This structure is inspired by a pattern that I've brought from Java/Maven, so I won't claim it's Pythonic, and I don't like the path manipulation where the tests are concerned (I know a lot of others won't, either, so beware!). In fact, I found this question while looking for a better way to do this.
To accomplish this you first have to set up a folder to serve as your 'resources' package (See the docs). Once that's done, you create a similar version for your tests, in the tests folder. The directory structure will look something like this:
Note that main and tests are NOT packages. This is what contradicts a lot of conventional guidance in Python project structure. Instead, they're both added to the path, with tests being inserted into the path in front of main, by the run_tests.py script using code like this (some bits borrowed from this post:
I'll typcially have additional options I want to feed pytest, and that's what
args
is for, but it's not relevant to this answer, so I left it empty here.I know this is a late answer, but I hope this helps someone. Also, I know it's a controversial approach, but it's the most satisfying approach I've found so far. That may be because I'm experienced in Java as well as Python. To others, the approach of trying the import of tests.resources, and importing main.resources if it fails may be preferable.
I hope anyone with other approaches to this will share in comments, or post additional answers.
根据这个找出了一些东西。
我最终在名为“tests”的文件夹中创建了一个测试配置文件,并将此代码放在使用它的每个文件的顶部:
我认为这不是最佳选择,因为我觉得这样的东西应该出现在测试代码中,另外,它使新的配置文件成为一个永远不应该更改的依赖项,以免破坏所有内容,但我想如果您像我一样不知道这些破解的测试库如何工作,那么它现在可以工作。
Figured out something based on this.
I ended up creating a testing config file in my folder named "tests" and having this code at the top of every file that used it:
I don't think it's quite optimal since I feel something like this should be in the testing code, plus it kind of makes the new config file a dependency that should never be changed lest you break everything, but I guess it works for now if you have no clue how these cracked testing libraries work like me.