truethe module can be additionally used in acceptance and functional tests to acccess WordPress code in the tests context. This module is a wrapper around the functionalities provided by the WordPress PHPUnit Core test suite, as such it provides the same method and facilities. The parameters provided to the module duplicate the ones used in the WordPress configuration file: the
WPLoadermodule will not bootstrap WordPress using the
wp-config.phpfile, it will define and use its own WordPress configuration built from the module parameters.
loadOnly: false) exactly as the the WordPress PHPUnit Core test suite it is based on, this module will operate any change to the database in a transaction. This means that, in the context of integration tests, the result of any write or delete operation done during the tests will be rolled back at the end of each test method; this is done for a number of reasons like performance and tests independence. Inspection of the database during tests, e.g. stopping execution using XDebug, will not show any change in the database. Keep this in mind while trying to debug integration tests using the
WPLoadermodule. When configured to only load WordPress (
loadOnly: true) then any database operation will be committed and written to the database.
wpRootFolderrequired The absolute, or relative to the project root folder, path to the root WordPress installation folder. The WordPress installation root folder is the one that contains the
dbNamerequired - The name of the database used by the WordPress installation, same as the
dbHostrequired - The host of the database used by the WordPress installation, same as the
DB_HOSTconstant. If the database is accessible (as is the case on the latest version of [Local by Flywheel][http://localwp.com]) via unix socket, then the string to insert here should look like this
dbUserrequired - The user of the database used by the WordPress installation, same as the
dbPasswordrequired - The password of the database used by the WordPress installation, same as
loadOnly- defaults to
false; whether to only load WordPress, without bootstrapping a fresh installation for tests or not. Read more in the "Using WPLoader in acceptance and functional tests" section. If this parameter is set to
truethe following parameters will not apply.
isolatedInstall- defaults to
true, whether to install and bootstrap the WordPress installation in a secondary PHP thread for thread safety or not. Maintained for back-compatibility purposes with wp-browser first versions: to get a replica of the bootstrap process used by WordPress Core PHPUnit tests leave this to
installationTableHandling- defaults to
empty; it controls how tables created by WordPress and plugins will be handled during the installation of WordPress during tests. By default tables will be emptied of any content, but some plugins might require tables to be dropped before WordPress is installed and after plugins are activated (this used to be the default behavior). Supported values are
dropto drop the tables,
emptyto just empty the tables and
letto do nothing about the tables. If you get errors from database queries while the
WPLoadermodule installs the tests, then try changing this parameter value.
wpDebug- defaults to
true, the value the
WP_DEBUGconstant will be set to.
multisite- defaults to
false, the value the
MULTISITEconstant will be set to.
skipPluggables- defaults to
false, if set to
truewill skip the definition of pluggable functions.
dbCharset- defaults to
utf8, the value the
DB_CHARSETconstant will be set to.
dbCollate- defaults to an empty string, the value the
DB_COLLATEconstant will be set to.
tablePrefix- defaults to
wptests_, the value the
$table_prefixvariable will be set to.
domain- defaults to
example.org, the domain of the WordPress site to scaffold for the tests.
title- defaults to
Test Blog, the title of the WordPress site to scaffolded for the tests.
phpBinary- defaults to
php, the PHP binary the host machine will have to use to bootstrap and load the test WordPress installation.
language- defaults to an empty string, the language of the WordPress installation to scaffold.
configFile- defaults to an empty string, an additional configuration file to include before loading WordPress. Any instruction in this fill will run before any WordPress file is included.
contentFolder- defaults to an empty string; the path, relative to the
wpRootFolderor absolute, to the content folder if different from the default one or the one defined by the
WP_CONTENT_DIRconstant; if the
WP_CONTENT_DIRconstant is defined in a config file (see the
configFileparameter) this will be ignored.
pluginsFolder- defaults to an empty string; the path, relative to the
wpRootFolderor absolute, to the plugins folder from the
wpRootFolderif different from the default one or the one defined by the
WP_PLUGIN_DIRconstant; if the
WP_PLUGIN_DIRconstant is defined in a config file (see the
configFileparameter) this will be ignored.
plugins- defaults to an empty string; a list of plugins that should be loaded before any test case runs and after mu-plugins have been loaded; these should be defined in the
activatePlugins- defaults to an empty string, a list of plugins that will be activated before any test case runs and after WordPress is fully loaded and set up; these should be defined in the
folder/plugin-file.phpformat; when the
multisiteoption is set to
truethe plugins will be network activated during the installation.
bootstrapActions- defaults to an empty string, a list of actions or static functions that should be called after before any test case runs, after plugins have been loaded and activated; static functions should be defined in the YAML array format:
theme- defaults to an empty string, the theme that should be activated for the tests; if a string is passed then both
stylesheetoptions will be set to the passed value; if an array is passed then the
stylesheetwill be set in that order:
templatewill be set to
stylesheetwill be set to
WP_UnitTestCasetest case class; while the module will load fine and will raise no problems
WP_UnitTestCasewill take care of handling the database as intended and using another test case class will almost certainly result in an error if the test case defines more than one test method.
tests/my_suite/Acme/UserTest.phpclass. The class extends the
Codeception\TestCase\WPTestCaseclass provided by wp-browser; this looks like a normal PHPUnit test case but has some perks due to it's mixed breed nature. Understanding them might help you work with it:
post_providermethod wil generate a function not found exception when the test case runs as the WordPress defined methods are not loaded yet:
static::factory()method; in this instance too there are too many methods to list them all but it's worth noting how easy it is to set up test fixtures with the factory:
factoryproperty can be accessed on the
testerproperty too and will work the same way as if called using
loadOnlyparameter should be set to
true; this could be the case for functional tests in need to access WordPress provided methods, functions and values. An example configuration for the module in this mode is this one:
WPDbmodule to provide the tests with a WordPress installation suiting the tests at hand; when doing so please take care to list, in the suite configuration file
modulessection (see example above) the
WPDbmodule before the
WPLoaderone. Codeception will initialize the modules in the same order they are listed in the modules section of the suite configuration file and the WPLoader module needs the database to be populated by the
WPDbmodule before it runs! As an example this is a correct suite configuration:
string$path - An optional path to append to the content directory absolute path.
WP_PLUGIN_DIRconstant, then the
pluginsFolderconfiguration parameter and will, finally, look in the default path from the WordPress root directory.
string$path - A relative path to append to te plugins directory absolute path.
allfilters and actions to debug their value.
\callable$format - A callback function to format the arguments debug output; the callback will receive