First version of WordPress functional testing dedicated module is out.
On GitHub
The new version of wp-browser is tagged 1.15.0 and contains the new WordPress module.
The module follows Codeception convention of naming functional tests dedicated modules as the framework itself and it feels like a good accomplishment.
An example
I’ve gone into detail enough to skip the part where I explain why I felt the wp-browser library needed a module dedicated to functional testing and am able, as such, to admit that it does satisfy my sense of completion.
To showcase what the new WordPress module can do I’ve updated the [“I’d like this”](https://github.com/lucatume/idlikethis ‘“I’d like this”') plugin repository to use the module in the functional test suite.
Inherent limits
Functional testing has, according to the definition the Codeception site sports, some characteristics:
[…] functional tests don’t require a web server to run tests. In simple terms we set $_REQUEST, $_GET and $_POST variables and then we execute the application from a test. This may be valuable as functional tests are faster and provide detailed stack traces on failures.
The module will allow making requests directly to WordPress relevant files like the root or admin area index.php files but will not, due to WordPress inherent limits, run the tests in the same variable space as the test methods.
Once again quoting the Codeception website:
If your application was not designed to run in long living process, for instance you use exit operator or global variables, probably functional tests are not for you.
WordPress was not designed to run in long living processes and yes: it does use some global variables.
One of the common issues with functional tests is usage of PHP functions that deal with headers, sessions, cookies. As you know, header function triggers an error if it is executed more than once for the same header. In functional tests we run the application multiple times, thus, we will get lots of trash errors in the result.
WordPress loves the header function.
In functional testing, unlike the traditional way, PHP application does not stop after it finished processing a request. As all requests run in one memory container they are not isolated. So if you see that your tests are mysteriously failing when they shouldn’t - try to execute a single test. This will check if tests were isolated during run. Because it’s really easy to spoil environment as all tests are run in shared memory. Keep your memory clean, avoid memory leaks and clean global and static variables.
WordPress will not keep the memory clean. To cope with all that each request will run in an isolated parallel process handled by the Symfony\Process component; headers and cookies are intercepted using WordPress filters and actions and it seems to work.
Still a work in progress
The module is still a work in progress; it covers the first requirements I could come up with and is far from being complete; yet it’s a start I’m willing to experiment with and will experiment with.
I will delve into a simple WordPress plugin development in the days to come to illustrate some use cases.