PHPUnit 和自动加载器：确定代码是否在测试范围内运行？
前提
我知道编写代码以在运行测试时采取不同的行为是非常糟糕的做法，但我可能实际上遇到过一种可能有必要这样做的场景。
具体来说，我正在尝试测试 Zend 框架中 HTML Purifier 的一个非常具体的包装器 - 确切地说，是一个视图助手。 HTML Purifier 自动加载器是必要的，因为它使用与我们其他自动加载器不同的逻辑。
问题
require() - 在我的 View Helper 类顶部使用自动加载器，在测试范围内给出以下内容：
HTML Purifier 自动加载器注册器不兼容 由于 PHP Bug #44144，使用非静态对象方法； 请不要使用 HTMLPurifier.autoload.php（或任何 包含此文件的文件）；相反，放置代码： spl_autoload_register(array('HTMLPurifier_Bootstrap', '自动加载')) 在您自己的自动加载器之后。
正如广告中所说，将 require() 替换为 spl_autoload_register(array('HTMLPurifier_Bootstrap', 'autoload')) 意味着测试运行良好，但 View Helper 却死得很惨。 ：
Zend_Log[3707]：ErrorController 捕获 LogicException“传递的数组未指定现有静态方法（未找到类“HTMLPurifier_Bootstrap”）”
（我们的测试文件夹结构必然与我们的 Zend 文件夹结构略有不同。）
问题
修补后的 有了它，我想我需要根据东西是否在测试范围内来选择自动加载器加载。
我是否还有其他选项可以在这两种情况下包含 HTMLPurifier 的自动加载例程，但由于视野狭隘，我没有看到这
如果没有，我是否必须找到一种方法来用我自己的代码（例如 APPLICATION_ENV）来区分测试环境和生产环境 - 或者 PHPUnit 通过设置一个我可以的常量来本地支持我的这个可怕的黑客行为检查它是否被定义（），或类似的恶作剧？ （我的 Google-fu 很弱！我可能只是做错了。）
Premise
I know that writing code to act differently when a test is run is hilariously bad practise, but I may've actually come across a scenario in which it may be necessary.
Specifically, I'm trying to test a very specific wrapper for HTML Purifier in the Zend framework - a View Helper, to be exact. The HTML Purifier autoloader is necessary because it uses a different logic to the autoloaders we otherwise have.
Problem
require()-ing the autoloader at the top of my View Helper class, gives me the following in test-scope:
HTML Purifier autoloader registrar is not compatible
with non-static object methods due to PHP Bug #44144;
Please do not use HTMLPurifier.autoload.php (or any
file that includes this file); instead, place the code:
spl_autoload_register(array('HTMLPurifier_Bootstrap', 'autoload'))
after your own autoloaders.
Replacing the require() with spl_autoload_register(array('HTMLPurifier_Bootstrap', 'autoload')) as advertised means the test runs fine, but the View Helper dies a terrible death claiming:
Zend_Log[3707]: ErrorController caught LogicException "Passed array does not specify an existing static method (class 'HTMLPurifier_Bootstrap' not found)"
(Our test folder structure is slightly different to our Zend folder structure by necessity.)
Question(s)
After tinkering with it, I'm thinking I'll need to pick an autoloader-loading depending on whether things are in the test scope or not.
Do I have another option to include HTMLPurifier's autoloading routine in both cases that I'm not seeing due to tunnel vision?
If not, do I have to find a means to differentiate between test-environment and production-environment this with my own code (e.g. APPLICATION_ENV) - or does PHPUnit support this godawful hackery of mine natively by setting a constant that I could check whether its been defined(), or similar shenanigans? (My Google-fu here is weak! I'm probably just doing it wrong.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
HTML Purifier 将其自动加载代码放置在与 HTMLPurifier.auto.php 不同的文件中；即HTMLPurifier_Bootstrap。它有两个方法：autoload，它实际上执行自动加载，以及 getPath，它不包含文件 put 告诉您文件的位置。该文件明确设计为独立的。
不幸的是我没有资格谈论 Zend 的代码。在尝试代码之前，您也许可以对 Bootstrap 进行额外的包含。希望有帮助！
HTML Purifier has its autoloading code placed in a file distinct from HTMLPurifier.auto.php; namely HTMLPurifier_Bootstrap. It has two methods: autoload, which actually performs an autoload, as well as getPath, which doesn't include a file put tells you where the file would be. This file is explicitly designed to stand alone.
Unfortunately I'm not qualified to speak about Zend's code. You might be able to just get away with doing an extra include to Bootstrap before attempting the code. Hope that helps!
好吧，尽管您对生产和测试环境之间的相似性（如果不是同一性）要求的看法是正确的 - 我的配置仍然有些不同。我的意思是引导加载 application.ini 中的不同部分，因此我可以简单地传递标志来打开/关闭某些东西（就像自动加载器功能）：
1）我在 .htaccess 中有 SetEnv APPLICATION_ENV 测试（可能是生产、开发 ） 、分期）。您也可以将它添加到您的 apache 配置中。
2）当 Zend_Config 加载 application.ini 时 - 它根据 get_env('APPLICATION_ENV') 加载它 - 所以不同的场景有不同的部分（当然我实际上依赖于 Zend_Application，但它足够聪明来理解环境）
3）我总是可以在相应的部分添加一些标志并从代码中检查它。
希望这会有所帮助。
Well, although you are right about similarity (if not identity) requirement between production and test environments - I still have the configuration somewhat different. I mean bootstrapping loads different sections from application.ini, and as such I can simply pass the flag to turn sth on/off (like that autoloader feature):
1) I have SetEnv APPLICATION_ENV test in my .htaccess (could be production, development, staging). You can have it in your apache configs as well.
2) When Zend_Config loads application.ini - it loads it according to get_env('APPLICATION_ENV') - so different sections for different scenarios (I actually rely on Zend_Application of course, but it is clever enough to understand the environment)
3) I can always add some flag into respective section and check it from code.
Hope this helps a little.