Handling different database dump URLs in WordPress testing.
The problem
I’ve had back and forth feelings about the use of database dumps as starting points in WordPress acceptance tests. The main issue with them being WordPress hardcoding the site URL address in the options table.
The values stored in the home and siteurl options will be looked up by WordPress any time it needs to generate a permalink and the posts table will contain absolute URLs in the guid column.
That’s not the whole picture but one that gives a good idea about the complications involved in sharing a WordPress database dump as test fixtures.
A tool like the WP-CLI search-replace command solves exactly that problem but that relies on a live database using a live WordPress installation.
A solution
To tackle this issue and others of a more complex nature I’ve developed the codeception-setup-local package but that might be an overkill to handle this glorified string replacement issue. Latest version of WP Browser features an update to the WPDb module that, when instructed to populate the test database from a dump file setting the populate parameter to true, will try to read the WordPress URL hardcoded in the dump file and replace it with the one specified in the urlparameter of the WPDb module.
To make an example if the developer that set up the starting database dump had WordPress served on http://localhost:8080when she exported the database dump and my WordPress local installation is served instead at 'http://wp.local then any recurrence of the former hardcoded URL will be replaced with the the latter without modifying the original dump file.
To prevent the module from attempting the replacement the urlReplacement parameter must be explicitly set to false.