Manual:PHP unit testing/Writing unit tests for extensions

The recommended bootstrapping method for extensions is to create your tests in the  directory of your extension (or use the UnitTestsList hook). Either of these methods will ensure MediaWiki core is bootstrapped for things like autoloading classes, global functions etc.

Two types of tests
MediaWiki supports "unit" tests and "integration" tests. The general idea is that with "unit" tests, you create mocks of all the objects that are used by methods you are testing. With integration tests, you have access to actual objects generated by other code, including data loaded from the database. If you are writing unit tests, extend MediaWikiUnitTestCase and place your tests in. If you are writing integration tests, extend MediaWikiIntegrationTestCase and place your tests in.

Create your tests
Let's say our Fruits extension has a class called. For integration tests that involve global state, MediaWikiServices, etc, extend  instead (formerly known as  ).
 * 1) Create a test file in your extension’s tests/phpunit/ directory, named
 * 2) * Make sure that the file name ends in  or else phpunit will not be able to discover it.
 * 3) Create a class in that file named   and extend the MediaWikiTestCase class.
 * 4) The class must contain a   that calls   as its first task.
 * 5) If you need to perform an operation on teardown of the test, the class may contain a   that calls   as its last task.
 * 6) Each of your test functions should :
 * 7) * be.
 * 8) * begin their function name with.
 * 9) It’s a good idea to add an   comment to the class. This group name can then be referred to later in order to run tests only in this group or exclude them. You can also place an   comment above each test function if you wish to further isolate your tests.
 * 10) * There are two special group names: " " and " ":
 * 11) *# Tests tagged into the group  are allowed to access the wiki's database and make destructive changes to the wiki; suites from extensions which are tagged this way are tested by Continuous Integration separately, in isolation from each other. Other tests are forbidden from making changes to the wiki, and will fail.
 * 12) *# Tests tagged into the group  are only run for patches to that repo, and not for other repos which depend on this one. This lets you write extensive, expensive tests for features your extension provides, without slowing down the test runs for other repos. You must get CI configured for your repo to run these tests; by default, the stand-alone test suite isn't run.

Single test file
If you are using vagrant and get an error message: "Cannot access the database: Unknown database", try adding  to the command line.

Create a custom test suite
runs with a default test suite defined in. You can alter that test suite by doing the following:  Copy the  file to  . Edit the suite.extensions.xml file: Save the file. Run the tests with the custom suite configuration.   Tests for any extension loaded in  will be run. If you want to isolate tests to only your extension, you can exclude groups of tests within the  file.
 * remove any unwanted from the  node.
 * add or make sure a node exists with the following:

List groups
You can get a list of test groups available for a specific configuration by running:

Exclude groups
You can then exclude specific test groups by adding them to the, node in  : Tests are considered part of a group when an  comment is placed above the class or function.
 * covers any test that has not been given an  comment.
 * phpunit also considers an  comment as an   comment, but   is preferred.