View on GitHub

mysql-unit

Testing framework for stored routines in MySQL

+--------------+---------------+---------+
| Installation | Documentation | Samples |
+--------------+---------------+---------+
1 row in set (0.00 sec)

Download this project as a .zip file Download this project as a tar.gz file

 

Common concept

To run tests, two things are needed. First, some place where tests data - such as testing expressions, their expected results e t.c. - is stored. Second thing is API, which will use that data and produce all checks which that data describes. This page contains explanation for both those things - how testing storage is organized and what API is provided by mysql-unit to produce test checks.

First thing to say about testing storage: it is stored in database. That means, during installation, all needed tables will be created, and in order to run tests, those tables should be used. So, you will have to know the structure of testing storage if you want to add tests there manually. (Currently, manual tests storage managing is the only way, but in future, the corresponding API will be added)

Next, all testing API in front is a call of MySQL procedure. That means - you'll use CALL to invoke them. Also, testing procedures will run till first failure. So, if failure happened, testing procedure will stop and display some information about - what had failed and why.

Testing storage structure

Storage for tests contains two parts: for functions testing and for procedure testing. There are differences in them, because procedures testing is much more complicated: inside procedures we can do DDL changes, other procedures calls, e.t.c. - thus, procedure testing part should handle all those things.

All storage tables are in upper case and starts with TEST_ prefix. Be careful - depending from OS your server may be sensitive or not to table names case. Since installation process contains DROP TABLE IF EXISTS statement, you should be aware about case-sensitivity, if your installation database already contains tables with such names, but in different case.

Functions testing storage

Storage for functions testing is represented by one single table. It's named TEST_FUNCTION_ASSERTIONS. Below is it's common structure:

Description for each field is:

Procedures testing storage

Storage for procedures testing is more complicated and consists of several tables. The model of testing is now not just iterate through all matched rows, but also to check multiple expressions for each test. Arguments list is also separated - that is because procedure call is not just a usual expression. Tables for this storage part:

Below is a diagram that illustrates relations between those tables:

As it was done for functions part, here is a description for each field of each table:

Testing API

As it was already said, testing API is always a procedure call. Procedure call result is SQL error code with some message or successful execution result. Also, if some test failed, it is possible to include failure description as a row set into result. This is useful, because external driver may capture both error and result set by single call.

Front API

There are basic wrappers for testing procedures, which are provided by framework. They are:

So, all front-API procedures have only one parameter, tested entity name. They are called "front-API" because they are just wrappers for main testing procedures. This procedures are easy to use, and, normally, they are enough to produce all desired testing results.

General API

However, under the hood of front-API procedures, there are two generic testing procedures, which will do all the work. They may be used to do custom test run (by test identifier), and, of course, as a replacement for front-API: