处理硬编码路径的回归测试
我需要扩展一个有大量硬编码路径的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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
在您的测试设置中,您可以使用从“假”目录结构读取的您自己的版本来覆盖正在测试的模块中的内置
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:您可以使用 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...