The slic (StellarWP Local Interactive Containers) CLI command provides a containerized and consistent environment for running automated tests.
One of the biggest stumbling blocks that engineers face when getting automated testing going for their projects is the complexity of setting up a testing environment. And as your team size grows, the struggles with consistent test running increase.
slic
automatically configures a Codeception testing environment so you don't have to.
Plus, it provides a lot of handy development tools and utilities that you can use while developing your project or during Continuous Integration builds!
Codeception is a PHP testing framework that uses PHPUnit under the hood, adding all sorts of extra features to make testing PHP much easier. By using Codeception, you then get the ability to use wp-browser, a module that greatly simplifies testing WordPress plugins, themes, and whole WP sites at all levels of testing.
» Learn more about wp-browser here and get it set up on your project.
You can see examples of what to toss in your
composer.json
in our stellarwp/schema repository.
Docker.
That's the only prerequisite. Get that installed and running on your machine and you'll be good to go!
These instructions are assuming that you are cloning the
slic
repository in~/projects
. If you want it in a different location, feel free to tweak the example commands below.
cd ~/projects
git clone git@github.com:stellarwp/slic.git
Assuming you are cloning the slic
repository in ~/projects
:
echo "export PATH=$HOME/projects/slic:$PATH" >> ~/.bashrc
source ~/.bashrc
If you are using zsh, change
~/.bashrc
to~/.zshrc
.
slic
is well documented within the CLI utility itself. To see all of the available commands, run:
slic help
You can see details and usage on each command by running:
slic help <command>
The slic
command has many subcommands. You can discover what those are by typing slic
or slic help
. If you want
more details on any of the subcommands, simply type: slic [subcommand] help
.
The slic
command needs a place to look for plugins, themes, and WordPress. By default, slic
creates a _plugins
and
_wordpress
directory within the local checkout of slic
. In most cases, however, developers like to run automated tests
against the paths where they are actively working on code – which likely lives elsewhere.
Good news! You can use the slic here
sub-command to re-point slic
's paths so it looks in the places you wish. There
are two locations you can tell slic
to look.
If you want to defer all of the WP site configuration to a dynamically pulled codebase and just worry about testing
plugins, you can run the slic here
command right from the parent directory of your project. Doing so will restrict slic
to running tests on subdirectories of where you ran the command.
Example:
# Change to your plugin containing dir (likely some path to wp-content/plugins)
cd /path/to/your/wp-content/plugins
slic here
The second option is to navigate to the root of your site (likely where wp-config.php
lives) and run the slic here
command.
Note: This is an opinionated option and there are some assumptions that are made:
- That the WordPress directory is the path you are indicating or in a sub-directory called
wp/
.- That the
wp-content/
(orcontent/
) directory is a sub-directory of the location in which you are typingslic here
.
# Change to your root directory of your site (where your wp-config.php file lives)
cd /path/to/your/site
slic here
By running slic here
at the site level, this allows you to set plugins, themes, or the site itself as the location
from which to run tests. This also has the benefit of running tests within the WP version that your site uses.
Before you can do anything productive with slic
, you need to tell it which
project you wish to use and then you can initialize the project, run tests, and
execute other commands to your heart's content!
Assuming you have a plugin called the-events-calendar
in the plugins directory
where you ran slic here
, you can tell slic
you want to take actions on that
plugin using the following command:
slic use the-events-calendar
For more information on this command, run
slic help use
.
With your desired plugin containing directory set, you will need to initialize plugins so that they are prepped and ready
for slic
-based automated test running. You do that using slic init [plugin]
.
Example:
slic init event-tickets
What this command does:
- Generates a
.env.testing.slic
env file in the plugin. - Generates a
test-config.slic.php
file in the plugin. - Generates a
codeception.slic.yml
file in the plugin. - Prompts for confirmation on running
composer
andnpm
installs on the plugin.
As mentioned above, you'll need to use Codeception for your automated testing and it is highly recommended that you make use of wp-browser - which adds a lot of WordPress helper functions and utilities.
Ok. You have slic
set up. It is pointing at your project. Your project has tests. Now you want to run one of your test suites. Let's pretend that your test suite is called wpunit
.
You can run the full suite like so:
slic run wpunit
Or, if you want an even more efficient way to do it, you can do:
slic shell
# You'll get a prompt once you are thrown into the shell
> cr wpunit
By default, slic
caches composer dependencies within the container
and, when the containers are destroyed, so is the cache. The good news
is that slic
allows you to map your machine's composer cache directory into
the slic
containers so that repeated slic composer
commands can benefit from
the cache as well!
# Feel free to change the path to whatever is appropriate for your machine.
slic composer-cache set $HOME/.cache/composer
For more information on this topic, type slic help composer-cache
.
By default, slic
uses composer v1 but you may also choose to use v2 by running the following command:
slic composer set-version 2
If you need to go back, just set the version back to 1:
slic composer set-version 1
If you want to know which version slic
is pointed at, you can always call:
slic composer get-version
If you need to install a private composer package, configure the COMPOSER_AUTH environment variable. For example, to install a package from a private GitHub repository:
Note: You may need to create a Personal Access Token.
export COMPOSER_AUTH='{"github-oauth": {"github.com": "YOUR_TOKEN_HERE"}}'
Then, restart slic and try again:
slic restart; slic composer update
Or, in a GitHub Action, for example:
jobs:
test:
runs-on: ubuntu-latest
env:
COMPOSER_AUTH: '{"github-oauth": {"github.com": "${{ secrets.GH_BOT_TOKEN }}"}}'
The slic
CLI command leverages .env.*
files to dictate its inner workings. It loads .env.*
files in the following order, the later files overriding the earlier ones:
.env.slic
- this is the default.env
file and should not be edited..env.slic.local
in the main slic directory - this file doesn't exist by default. Make overrides to all your projects (e.g.SLIC_GIT_HANDLE
) by creating it and adding lines to your heart's content..env.slic.local
in your target's directory - this file doesn't exist by default. Make overrides to a single project (e.g.SLIC_PHP_VERSION
)..env.slic.run
- this file is generated byslic
and includes settings that are set by specificslic
commands.
List the available Xdebug commands.
See if Xdebug is enabled or disabled, the host information, and the path mapping to add to your IDE.
Note that this command cannot be ran within slic shell
because you've SSH'd into the Codeception container which has no knowledge of slic.
See also: Configuring Xdebug
slic xdebug on
slic xdebug off
- Within
slic shell
:slic xon
slic xoff
Props to @lucatume, @borkweb, and The Events Calendar team for creating this tool and it's predecessor, tric
.