10up
Request: control Strict Mode per test
Feature request
Currently, in my bootstrap.php I typically use WP_Mock::activateStrictMode().
I would like to disable strict mode for some tests, in particular where I use WP_Mock::expectActionAdded(). Often, a function that adds one action adds many, but I will only be interested in testing that one add_action() I've most recently added.
With strict mode on, other add_action/add_filter calls without their corresponding WP_Mock::expectActionAdded() result in:
Unexpected use of add_action for action init with callback BrianHenryIE\Example::init
Proposed solution
Add a public setter on WP_Mock::$__strict_mode() that can be used during individual tests, then in TestCase::setUp() reset strict mode to the configured/default value.
WP_Mock::activateStrictMode() only allows setting it before boostrap, and the documentation says it has to be enabled before bootstrap, but WP_Mock::strictMode() is only actually used in one, two places that don't read to me like it would matter.
The feature tests are already enabling/disabling it as desired in FeatureContext::forceStrictModeOn().
Hi @BrianHenryIE thanks for looking into this and providing your thoughts about it.
I am curious, why would you want to have hooks registered but not testing for it. Doesn't that repected an expected and desired behaviour? which means they should be tests for.
WP_Mock::activateStrictMode()only allows setting it before boostrap, and the documentation says it has to be enabled before bootstrap, butWP_Mock::strictMode()is only actually used in one, two places that don't read to me like it would matter.
I see what you mean, but we have to consider other unknown use cases that whom ever using the package, would want to check/evaluate if strict mode is turned on or not depending of their test environment setup.
Add a public setter on WP_Mock::$__strict_mode() that can be used during individual tests, then in TestCase::setUp() reset strict mode to the configured/default value.
To better understand your point of view, can you open a simple PR to demonstrate that workflow change?
Looking forward your feedback.
why would you want to have hooks registered but not testing for it.
Well, yesterday I was working with a specific method in a class and its hook is added in a "register hooks" type function that registers all the hooks for that class. It's legacy code. I do want to test the action that I'm working with; I do not want to imply the other hooks are correctly tested. Of course, I'd love if everything were thoroughly tested!
I'll throw together a PR soon.
Thanks @BrianHenryIE for the clarification, Looking forward to that PR