Download the PHP package tarantool/phpunit-extras without Composer

PHPUnit Extras

A collection of helpers for PHPUnit to ease testing Tarantool libraries. It is based on rybakit/phpunit-extras, please refer to this package for more documentation.

Table of contents

• Installation
• Annotations
  • Processors
    • Lua
    • Sql
  • Requirements
    • LuaCondition
    • TarantoolVersion
• Expectations
  • Requests
  • Prepared statements
• Mocking
• Testing
• License

Installation

Annotations

Besides the annotations provided by the package rybakit/phpunit-extras, the library is shipped with annotations specific to Tarantool. The easiest way to enable them is by inheriting your test classes from Tarantool\PhpUnit\TestCase:

Another option is to register an extension called AnnotationExtension:

By default, the extension assumes that the Tarantool server you are going to connect to is available on 127.0.0.1:3301. You can customize the default settings by specifying either a DSN string or an array of options as extension configuration values:

or

On top of that, the configuration values can resolve environment variables, which might be useful if you need to share the same settings with a Tarantool instance file or any other script:

Once the annotations are configured, you can start using them:

Processors

Lua

Allows executing Lua code before running a test.

Example:

Sql

Allows executing SQL statements before running a test (requires Tarantool 2.0+).

Example:

Requirements

Requirements allow skipping tests based on preconditions.

LuaCondition

Format:

where <condition> is an arbitrary lua expression that should be evaluated to a Boolean value.

Example:

TarantoolVersion

Format:

where <version-constraint> is a composer-like version constraint. For details on supported formats, please see the Composer documentation.

Example:

If you're interested in how to create and register your own annotations and requirements, please refer to the rybakit/phpunit-extras README.

Expectations

Requests

To test that your code sends (or does not send) certain requests, the following methods are available:

• TestCase::expect<REQUEST_NAME>RequestToBeCalled(int $count) : void
• TestCase::expect<REQUEST_NAME>RequestToBeCalledAtLeast(int $count) : void
• TestCase::expect<REQUEST_NAME>RequestToBeCalledAtMost(int $count) : void
• TestCase::expect<REQUEST_NAME>RequestToBeCalledOnce() : void
• TestCase::expect<REQUEST_NAME>RequestToBeCalledAtLeastOnce() : void
• TestCase::expect<REQUEST_NAME>RequestToBeCalledAtMostOnce() : void
• TestCase::expect<REQUEST_NAME>RequestToBeNeverCalled() : void
• TestCase::expectNoRequestToBeCalled() : void

where <REQUEST_NAME> is the name of the request, for example Call, Insert, etc. These methods are part of the Tarantool\PhpUnit\TestCase class, but they can also be enabled through a trait:

Example:

Prepared statements

In order to assert prepared statement allocations, use the Tarantool\PhpUnit\Expectation\PreparedStatementExpectations trait, which contains the following methods:

• expectPreparedStatementToBe<TYPE>(int $count) : void
• expectPreparedStatementToBe<TYPE>AtLeast(int $count) : void
• expectPreparedStatementToBe<TYPE>AtMost(int $count) : void
• expectPreparedStatementToBe<TYPE>Once() : void
• expectPreparedStatementToBeNever<TYPE>() : void
• expectPreparedStatementToBe<TYPE>AtLeastOnce() : void
• expectPreparedStatementToBe<TYPE>AtMostOnce() : void

where <TYPE> is either Allocated or Deallocated.

Example:

To enable all the above expectation methods in one go, use the Tarantool\PhpUnit\Expectation\Expectations trait, or extend the Tarantool\PhpUnit\TestCase class.

Mocking

The library provides several helper classes to create test doubles for the Tarantool Сlient to avoid sending real requests to the Tarantool server. For the convenience of creating such objects, add the trait TestDoubleClient to your test class:

If your test cases extend the Tarantool\PhpUnit\TestCase class, this step is not needed because the trait is already included in that class.

A dummy client object can be created as follows:

To simulate specific scenarios, such as establishing a connection to a server or returning specific responses in a specific order from the server, use the facilities of the TestDoubleClientBuilder class. For example, to simulate the PING request:

Another example, sending two EVALUATE requests and returning a different response for each:

The above example can be simplified to:

Besides, the builder allows setting custom Connection and Packer instances:

Testing

Before running tests, the development dependencies must be installed:

Then, to run all the tests:

License

The library is released under the MIT License. See the bundled LICENSE file for details.