处理硬编码路径的回归测试

发布于 2024-09-30 02:55:22 字数 428 浏览 0 评论 0原文

我需要扩展一个有大量硬编码路径的Python代码
为了不搞乱一切,我想在修改之前为代码创建单元测试:它将作为我的新代码的非回归测试(不会有硬编码路径)

但是由于硬编码的系统路径,我将在 chroot 树中运行测试(我不想污染我的系统目录)
我的问题是我只想设置 chroot 来进行测试,这可以使用 os.chroot 仅使用 root 权限来完成(并且我不想以 root 身份运行测试脚本)

事实上,我只需要一个假的树目录,这样当 open('/etc/resolv.conf) 的代码检索到假的 resolv.conf 而不是我的系统时,

我显然不想替换自己的硬编码路径在代码中,因为它不是真正的回归测试

您知道如何实现这一点吗?

谢谢

请注意,所有访问的路径都可以通过用户帐户读取

I need to extend a python code which has plenty of hard coded path
In order not to mess everything, I want to create unit-tests for the code before my modifications: it will serve as non-regression tests with my new code (that will not have hard-coded paths)

But because of hard coded system path, I shall run my test inside a chroot tree (I don't want to pollute my system dir)
My problem is that I want to set up the chroot only for test, and this can be done with os.chroot only with root privileges (and I don't want to run the test scripts as root)

In fact, I just need a fake tree diretory so that when the code that open('/etc/resolv.conf) retrieves a fake resolv.conf and not my system one

I obviously don't want to replace myself the hard coded path in the code because it would not be real regression test

Do you have any idea how to achieve this?

Thanks

Note that all the path accessed are readable with a user accout

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

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

发布评论

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

评论(2

寒冷纷飞旳雪 2024-10-07 02:55:22

在您的测试设置中,您可以使用从“假”目录结构读取的您自己的版本来覆盖正在测试的模块中的内置 open

import mymod
import os.path

def chroot_open(filename,*args):
    filename = os.path.join("/home/you/fakeroot",filename)
    return open(filename,*args)

mymod.open = chroot_open

In your test set-up you could override the built-in open in the module that you are testing with your own version that reads from your "fake" directory structure:

import mymod
import os.path

def chroot_open(filename,*args):
    filename = os.path.join("/home/you/fakeroot",filename)
    return open(filename,*args)

mymod.open = chroot_open
伴我老 2024-10-07 02:55:22

您可以使用 setuid root 的辅助应用程序来运行 chroot;这将避免需要以 root 身份运行测试。当然,这可能仍然会导致本地 root 漏洞利用,因此只能采取适当的预防措施(例如在 VM 映像中)。

无论如何,任何使用 chroot 的解决方案本质上都是依赖于平台的,所以它相当尴尬。我必须承认,实际上我更喜欢 Dave Webb(覆盖 open)的想法......

You could use a helper application that is setuid root to run the chroot; that would avoid the need to run the tests as root. Of course, that would probably still open up a local root exploit, so should only be done with appropriate precautions (e.g. in a VM image).

At any rate, any solution with chroot is inherently platform-dependent, so it's rather awkward. I actually like the idea of Dave Webb (override open) better, I must admit...

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