lucatume
[DOC REQUEST] Alternative ways to test wp-cli commands.
Did you search the documentation first? Yes
What do you think is missing from the documentation? From my understanding, the WP-CLI module is pretty much the equivalent of selenium tests for the browser. They completely end to end. I can currently not think of any ways to test wp-cli commands besides having them inside a must-use plugin or using the db-dumb function.
This is kind of limiting for me as I want to test wp-cli commands that are part of a distributed library and not a full WordPress installation. This makes it kinda complicated to test both locally and especially in CI where I have to do some symlink magic before running my tests so that the wp-cli subprocess picks up my commands.
Do you have any examples of what you'd like to see added to the documentation?
If it's even possible, alternative ways to test wp-cli commands using the WP-CLI module.
The idea is an interesting one that would surely add value to wp-browser, thanks for bringing it up.
Could you make some examples of the kind of test you would like to be able to write? I'm better able to understand when I see the API I should code to, that's why I'm asking you this.
I don't have a concrete API in mind right now, the API from the cli module is fine. The problem is registering commands in the child process.
This is how I currently solve it.
https://github.com/snicco/better-wp-cli/tree/master/tests/wordpress
Codeception bootstrap: https://github.com/snicco/better-wp-cli/blob/master/tests/wordpress/bootstrap.php
Fake mu-plugin that is symlinked: https://github.com/snicco/better-wp-cli/blob/master/tests/wordpress/mu-plugin.php
Maybe an idea would be to use the symlink approach I employed there:
// ...
_before(CliTester $I) {
$I->haveWPCLICommandsAt('/path/to/wp-cli/commands.php');
}
For now, I think the symlink approach is our best bet. Because there is no way for wp-browser to know what commands should be registered in the child process. Anything including serializing closures is just meant to fail. Wouldnt go that route.
So I think the best we can do is ensure that this file is included in the child-process before wp-cli runs. And then the developer can register commands there.
In the linked repo the file going into haveWPCLICommands would be this one:
https://github.com/snicco/better-wp-cli/blob/master/tests/wordpress/mu-plugin.php
Looking at version 4, I think a viable API would be to have WPCLI::changePath(string $path) or something along these lines.
The configuration only requirement is path and the modules _reconfigure method should make this easy.
In version 3, the module bootstrapped wp-cli on its own with a more convolute approach (implying the problematic requirement of the wp-cli package) and changing path posed more challenges.
In version 4 WP CLI processes run from the download .phar package making changing the path much easier.
@lucatume
We did a ton of improvements of v3's CLI module in our fork:
https://github.com/snicco/wp-browser/commit/849191f6f9dd7497ada173de168c4d47a14a3171 (starting at this fork commit)
I don't remember if that ultimately was merged - I do remember opening a PR tho.
@calvinalkan That has been merged into version 3.
Most of that work was about environment variable handling. In version 4 the WPCLI module has been rewritten to use the Symphony Process component and that should take care of those issues.