Download the PHP package lucinda/unit-testing without Composer

On this page you can find all versions of the php package lucinda/unit-testing. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Example code of lucinda/unit-testing

Informations about the package unit-testing

PHP Unit Testing API

Table of contents:

About

This library was in part created out of frustration while working with PHPUnit, the standard solution used by over 99% of PHP applications that feature unit testing. This current software aims at building something that PHPUnit is not: a cleanly coded, zero dependencies API!

diagram

It only requires developer to follow these steps:

API is fully PSR-4 compliant, only requiring PHP8.1+ interpreter, SimpleXML + cURL + PDO extensions (latter for URI and SQL testing) and Console Table API (for displaying unit test results). To quickly see how it works, check:

Why Not PHPUnit

Everything about that PHPUnit reminds of bygone ages when developers built huge classes that do "everything" and knew nothing about encapsulation except keyword "extends" (doubters should check https://github.com/sebastianbergmann/phpunit/blob/master/src/Framework/TestCase.php all PHPUnit tests must extend!).

Can something better be done? Should unit testing APIs abide to good principles of object oriented programming or only the code that is being tested? IMHO, as long as a developer feels confortable working with a mess, it will become a bad precedent to build something similar later on. Something much better MUST be done!

Configuration

Similar to PHPUnit, configuration of unit tests is done via an XML file with following syntax:

Mandatory tag unit_tests stores the suite of unit tests to be executed. Each API under testing is identified by a unit_test tag which has following subtags:

These settings will be used to autoload classes test/sources classes whenever used: like in composer's case, you are required to fully qualify namespaces and end them with a backslash.

Optional tag servers stores connection settings for SQL servers that are going to be used in the unit tests, broken by ENVIRONMENT (value of ). Each server must reflect into a server subtag where connection is configured by following attributes:

Example: unit tests @ OAuth2 Client API

Implementation

Initialization

By simply running a Lucinda\UnitTest\Controller implementation (see installation section), classes in sources folder are mirrored into tests folder according to following rules:

This insures 100% coverage is maintained on every execution, leaving programmers to develop missing unit tests themselves

Development

In order to be covered, each tests class public method MUST return either a single Lucinda\UnitTest\Result instance or a list of former, depending on whether or not you desire one or more tests. Each test has a status (passed or not) and an optional message (containing details that identify test against siblings).

Example:

Execution

By simply running a Lucinda\UnitTest\Controller (see Lucinda\UnitTest\Result instances are collected. The logic is as following:

This abstract class comes with following methods of interest:

Method Arguments Returns Description
__construct string $xmlFilePath, string $developmentEnvironment void Reads xml based on development environment, creates missing unit tests and executes them all for each API referenced
abstract protected handle Lucinda\UnitTest\Result[] void Handles unit test results by storing or displaying them.

API comes already with two with two Lucinda\UnitTest\Controller implementations:

Developers can build their own extensions that also save results somewhere...

Installation

In folder where your API under testing resides, run this command in console:

Then create a unit-tests.xml file holding configuration settings (see configuration above) and a test.php file with following code:

To see a live example of usage, check unit tests for OAuth2 Client API!

Assertions

Assertions on Primitive Values

API allows you to make assertions on all PHP primitive data types:

Each of these classes has a constructor in which a value of respective type is injected then a number of methods that make assertions on that value. In real life, you will only use those classes to make single assertions.

Assertion example:

Assertions on SQL Queries Results

Sometimes it is necessary to test information in database as well. For this you can use Lucinda\UnitTest\Validator\SQL class provided by API, which has four public methods:

Method Arguments Returns Description
static setDataSource Lucinda\UnitTest\Validator\SQL\DataSource void Sets a data source encapsulating settings to use in connection to server later on
static getInstance void Lucinda\UnitTest\Validator\SQL Opens single connection to SQL server using PDO based on data source injected beforehand then starts a transaction
__destruct void void rolls back transaction and closes connection to SQL server
assertStatement string $query, Lucinda\UnitTest\Validator\SQL\ResultValidator $validator Lucinda\UnitTest\Result Executes a SQL statement and asserts result by delegating to validator received as argument
assertPreparedStatement string $query, array $boundParameters, Lucinda\UnitTest\Validator\SQL\ResultValidator $validator Lucinda\UnitTest\Result Executes a SQL prepared statement and asserts result by delegating to validator received as argument

Assertion example:

Above mechanism allows you to develop MULTIPLE assertions on a single Lucinda\UnitTest\Validator\SQL instance, which in turn corresponds to a single SQL connection.

Assertions on URL Execution Results

Sometimes it is necessary to test results of URL execution. For this you can use Lucinda\UnitTest\Validator\URL class provided by API, which has two public methods:

Method Arguments Returns Description
__construct Lucinda\UnitTest\Validator\URL\DataSource $dataSource void Opens connection to an URL using Lucinda\UnitTest\Validator\URL\Request based on information encapsulated by Lucinda\UnitTest\Validator\URL\DataSource then collects results into a Lucinda\UnitTest\Validator\URL\Response instance.
assert Lucinda\UnitTest\Validator\URL\ResultValidator $validator Lucinda\UnitTest\Result Asserts response instance above by delegating to validator received as argument

Assertion example:

Above mechanism allows you to develop MULTIPLE assertions on same URL execution result via a single Lucinda\UnitTest\Validator\URL instance.

Assertions on Files

One can perform assertions on files by using Lucinda\UnitTest\Validator\Files class, which comes with following public methods:

Method Arguments Returns Description
__construct string $path void Records path to file under testing
assertExists string $message="" Lucinda\UnitTest\Result Asserts if file exists
assertNotExists string $message="" Lucinda\UnitTest\Result Asserts if file not exists
assertContains string $expected, string $message="" Lucinda\UnitTest\Result Asserts if file contains expected string
assertNotContains string $expected, string $message="" Lucinda\UnitTest\Result Asserts if file doesn't contain expected string
assertSize int $count, string $message="" Lucinda\UnitTest\Result Assert if file is of expected size
assertNotSize int $count, string $message="" Lucinda\UnitTest\Result Assert if file is not of expected size

Assertion example:

Examples

This OAuth2 Client API is among others that use this API for unit testing, so check:

All versions of unit-testing with dependencies

PHP Build Version
Package Version
Requires php Version ^8.1
ext-simplexml Version *
ext-curl Version *
ext-pdo Version *
ext-tokenizer Version *
lucinda/console Version ~2.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package lucinda/unit-testing contains the following files

Loading the files please wait ....