Download the PHP package otgs/unit-tests-framework without Composer
On this page you can find all versions of the php package otgs/unit-tests-framework. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download otgs/unit-tests-framework
More information about otgs/unit-tests-framework
Files in otgs/unit-tests-framework
Package unit-tests-framework
Short Description A framework to build unit tests with OTGS products
License GPL-2.0
Homepage https://git.onthegosystems.com/shared/otgs-unit-tests-framework
Informations about the package unit-tests-framework
PhpUnit
- Create a
tests
directory in your project - Create a
phpunit
subdirectory intests
[^1] - Copy
samples/phpunit.xml
file in the root of your project[^2]- Change
test-suite-name
into something appropriated - Most likely, you won't need to change anything else in that file
- Change
- Copy
samples/bootstrap.php
intotests/phpunit
- Read the comments in this file and make the appropriated changes
- Run
composer require --dev otgs/unit-tests-framework
[^3] - Create another
tests
subdirectory intests/phpunit
- Write your tests there
- Unless you have customized the
phpunit.xml
file, you don't need to name the test files and classes in any particular way
- Run
phpunit
from your project's root to start your tests[^4]
[^1]: it is recommended to keep your PHPUnit tests into a subfolder, because there are good changes you want to add other kind of tests (e.g. QUnit, PHPSpec, etc.)
[^2]: in case, for whatever reason, you can't do that, copy this file in tests/phpunit
or wherever you find it more convenient
[^3]: In some cases, you may want to use composer require --dev otgs/unit-tests-framework:dev-develop
. When you do that, you may also need to run this command first composer config minimum-stability dev
[^4]: If you've placed the phpunit.xml
you need to either move to that directory first, or tell phpunit where the file is with phpunit --configuration path/to/phpunit.xml
How to use the OTGS_TestCase class
In order to take the most of this library, all your tests classes should extext OTGS_TestCase
.
Once you do that, this will happen:
\OTGS_TestCase::setupBeforeClass
:$_GET
and$_POST
are set to an empty array- An instance of
FactoryMuffin
is provided: you can refer to it asself::$fm
(see "Resources and dependencies" for more details)
\OTGS_TestCase::setUp
FunctionMocker
is initialized (see "Resources and dependencies" for more details)WP_Mock
is initialized (see "Resources and dependencies" for more details)
\OTGS_TestCase::tearDown
WP_Mock
is destroyedFunctionMocker
is destroyedMockery
is destroyed (just in case it has been used)
\OTGS_TestCase::tearDownAfterClass
- Deletes all models created with
FactoryMuffin
- Deletes all models created with
Mock WP Core functions
This class also provide an helper method to quickly mock the functions defined by WordPress by using the \OTGS_TestCase::get_mocked_wp_core_functions
which returns an instance of OTGS_Mocked_WP_Core_Functions
.
OTGS_Mocked_WP_Core_Functions
organize mocks in methods named using the same name of the file where the function is defined in WordPress codebase.
For instance, to mock of all functions defined in post.php
like get_post
, in your test you should simply call $this->get_mocked_wp_core_functions()->post()
.
To mock add_query_arg
yo call $this->get_mocked_wp_core_functions()->functions()
because add_query_arg
is defined in functions.php
.
OTGS_Mocked_WP_Core_Functions
tries to handle dependencies.
So, if you call $this->get_mocked_wp_core_functions()->post()
to mock wp_insert_post
, you automatically call $this->get_mocked_wp_core_functions()->post()
, so to get all the meta related functions mocked as well.
Finally, there is a "mock all" method you could use (though is discouraged) with $this->mock_all_core_functions()
.
Stub WP common classes
\OTGS_TestCase
provides a helpful way to quickly get a stub of some of the most commonly used classes in WordPress.
By calling $this->stubs->wpdb()
you will get a stub you can pass as a dependency of the classes you are testing.
If you need to control the behavior of this stub, you just use the standard PHPUnit mock helpers.
E.g. 1:
E.g. 2:
Other stubs you can get:
WP_Widget
with$this->stubs->WP_Widget()
WP_Theme
with$this->stubs->WP_Theme()
WP_Filesystem_Direct
with$this->stubs->WP_Filesystem_Direct()
WP_Query
with$this->stubs->WP_Query()
It is important to know that, if you only need the class to be defined (e.g. hard-dependency, or sub-classing), you don't need to assig the stub to a variable: just call the method.
A good example is with WordPress' widgets, where you may have your own widget which is supposed to extend WP_Widget
.
In this case, unless you want to mock some of the WP_Widget
methods, you simply call $this->stubs->WP_Widget()
, then write your tests.
The class which extends WP_Widget
will find a definition of this class, with all the methods (doing nothing).
Resources and dependencies
Below are some resources on writing unit tests which lead to the creation of this library and links to the libraries included here:
- Start from here for a general explanation: http://wordpress.stackexchange.com/a/164138/7291
- 10up's WP_Mock`: https://github.com/10up/wp_mock
- Mockery: https://github.com/padraic/mockery
- Function mocker: https://github.com/lucatume/function-mocker
- Factory Muffin: https://github.com/thephpleague/factory-muffin
- Factory Muffin Faker: https://github.com/thephpleague/factory-muffin-faker
- The DomCrawler Component: http://symfony.com/doc/current/components/dom_crawler.html
- The CssSelector Component: http://symfony.com/doc/current/components/css_selector.html
- php-loremipsum: https://github.com/joshtronic/php-loremipsum
All versions of unit-tests-framework with dependencies
10up/wp_mock Version ^0.4
lucatume/function-mocker Version ^1.3
symfony/dom-crawler Version ^5.0
symfony/css-selector Version ^5.0
phpunit/phpunit Version ^8.5