Download the PHP package mindplay/testies without Composer

mindplay/testies

Yeah, testies: a lightweight library of functions for quick, simple unit-testing.

Tries to honor the Go language philosophy of testing - paraphrasing:

testing frameworks tend to develop into mini-languages of their own, with conditionals and controls and printing mechanisms, but PHP already has all those capabilities; why recreate them? We'd rather write tests in PHP; it's one fewer language to learn and the approach keeps the tests straightforward and easy to understand.

The primary test API is a set of functions in the mindplay\testies namespace.

Internally, the API is backed by a pair of simple "driver" and configuration classes - these are left as open as possible, and you should feel comfortable extending these and tailoring them specifically to suit the test-requirements for whatever you're testing.

Usage

Install via Composer:

composer require-dev mindplay/testies

Then create a test script - the format is pretty simple:

You can call test() as many times as you need to - the tests will queue up, and execute when you call run().

API

The following functions are available in the mindplay\testies namespace:

Rather than providing hundreds of assertion functions, you perform assertions using PHP expressions, often in concert with your own helper functions, or built-in standard functions in PHP - some examples:

We find that idiomatic PHP code is something you already know - rather than inventing our own domain-specific language for testing, we believe in writing tests that more closely resemble ordinary everyday code.

Custom Assertion Functions

Your custom assertion functions, like the built-in assertion functions, are just functions - usually these will call back to the ok() function to report the result. For example:

You can use the same approach to group multiple assertions for reuse:

Note that the diagnostic output will always refer to the line number in the test-closure that generated the assertion result.

Test Server

⚠️ This feature is still rough.

PHP provides a built-in development web server.

For basic integration tests, a simple wrapper class to launch and shut down a server is provided - the following example uses nyholm/psr7 and the zaphyr-org/http-client client library:

Note that the server is automatically shut down when the $server object falls out of scope - if you need to explicitly shut down a server, just destroy the server object with e.g. unset($server).

Keep in mind that starting and stopping many server instances can slow down your test drastically - it's often a good idea to open one server instance and share it between test-functions. Creating and disposing of clients, on the other hand, is recommended, as sharing client state could lead to unreliable tests.

Options

A few simple configuration options are provided via the configure() function, which provides access to the current instance of TestConfiguration.

Code Coverage

To enable code coverage and display the summary result on the console:

To output a clover.xml file for integration with external analysis tools, specify an output path:

To enable code coverage analysis only for files in certain folders, pass a path (or array of paths) like so:

Verbosity

By default, test output does not produce messages about successful assertions, only failures - if you want more stuff to look at, enable verbose output:

You can also enable this from the command line with the -v or --verbose switch.

Strict Error Handling

By default, all PHP errors/warnings/notices are automatically mapped to exceptions via a simple built-in error handler. If you're testing something that has custom error handling, you can disable it with:

Extensibility

The procedural API is actually a thin layer over two classes providing the actual library implementation.

One common reason to use a custom driver, is to override the TestDriver::format() method, to customize how special objects are formatted for output on the console.

To use a custom, derived TestConfiguration class:

Then proceed with business as usual.

To use a custom, derived TestDriver class:

Alternatively, create a configuration class that provides a custom default driver class:

Refer to the actual implementations to see what else is possible - pretty much everything is public or protected in these classes, left open for you to call or override as needed.