PHPUnit
The newly ported modules have some test coverage, which can be checked with PHPUnit.
Writing custom tests
The mongodb
module provides a Drupal\Tests\mongodb\Kernel\MongoDbTestBase
base class on which to build custom kernel tests for bespoke modules, as it
provides a per-test database created during test setUp()
, and
dropped during tearDown()
.
The base class is documented on the mongodb documentation page.
Complete test example
This example show how to write a test using a custom foo
database for the
eponymous module foo
, assuming individual tests do not drop the database
instance themselves.
<?php
namespace Drupal\\Tests\foo\Kernel;
use Drupal\mongodb\MongoDb;
use Drupal\Tests\mongodb\Kernel\MongoDbTestBase;
/**
* @coversDefaultClass \Drupal\foo\Foo
*
* @group foo
*/
class FooTest extends MongoDbTestBase {
const MODULE = 'foo';
protected static $modules = [
MongoDb::MODULE,
static::MODULE,
];
/**
* The test database.
*/
protected $database;
/**
* Override getSettingsArray method to include custom test database
*/
public function getSettingsArray(): array {
$settings = parent::getSettingsArray();
$settings[MongoDb::MODULE]['databases']['foo_alias'] = [
static::CLIENT_TEST_ALIAS,
$this->getDatabasePrefix(),
];
return $settings;
}
/**
* Add a custom alias to settings and instantiate a custom database.
*
* If the tests do not need a specific database, no setUp()/tearDown() is
* even needed.
*/
public function setUp(): void {
parent::setUp();
$this->database = new DatabaseFactory(
new ClientFactory($this->settings),
$this->settings
)->get(static::MODULE);
}
/**
* Drop the custom database.
*
* If the tests do not need a specific database, no setUp()/tearDown() is
* even needed.
*/
public function tearDown(): void {
$this->database->drop();
parent::tearDown();
}
/**
* @covers ::whatever
*/
public function testWhatever() {
// ... custom test logic...
}
}
In most cases, modules implementing will implement multiple classes, hence have
multiple tests, in which case having a per-module base test class will be
recommended. See mongodb_storage
or mongodb_watchdog
tests for examples.
Running tests
Now that Simpletest has been deprecated since Drupal 8.8, and its UI is going away (cf. #2566767), tests should be run from the PHPUnit command line.
Running directly
The typical full command to run tests looks like the next example (\
is to
avoid too long a line). Assuming a composer-project
deployment with Drupal in
the web/
directory, you'll need to run phpunit from the Drupal root, not the
project root:
cd web
SIMPLETEST_BASE_URL=http://localhost \
BROWSERTEST_OUTPUT_DIRECTORY=/some/writable/pre-existing/path \
SIMPLETEST_DB=mysql://user:pass@localhost/drupal10 \
MONGODB_URI=mongodb://somemongohost:27017 \
../vendor/bin/phpunit -c $PWD/core/phpunit.xml.dist \
-v --debug --coverage-clover=/tmp/cover.xml \
modules/contrib/mongodb
- Functional tests: the
SIMPLETEST_BASE_URL
andBROWSERTEST_OUTPUT_DIRECTORY
variables are needed. Kernel and Unit tests do not need them. - Optional:
MONGODB_URI
points to a working MongoDB instance. If it is not provided, the tests will default tomongodb://localhost:27017
.
These variables can also be set in the core/phpunit.xml
custom configuration
file to simplify the command line, as described on Drupal.org Running PHPUnit tests
page.
For functional tests to be more apt to catch some URL resolution issues, your test site should be using a subpath, i.e.:
- Good
http://drupaltest.localhost/somepath
- Not so good:
http://drupaltest.localhost
Using a phpunit.xml
configuration file
The test command can also be simplified using a phpunit.xml
configuration file:
phpunit -c core/phpunit.xml
Or to generate a coverage report:
phpunit -c core/phpunit.xml --coverage-html=/some/coverage/path modules/contrib/mongodb
In this syntax, core/phpunit.xml
is a local copy of the default
mongodb/core.phpunit.xml
configuration file, tweaked for the local
environment.