Restrictions
Despite such things as dynamic expression evaluation or nested exceptions handling, mysql-unit has it's limitations. It's core uses generic MySQL stored code, thus, some of those limitations are derived from that. Also, mysql-unit is using some database - the one, to which it is installed, which also may cause some restrictions.
In most cases, you can overcome this limitations, but still it is not always possible. And, if some of those restrictions are important for your system, then, probably, you'll not be able to use mysql-unit for testing your entities
On Tested Entities
Currently, there is impossible to:
- Test code in triggers. This functionality may be added in next versions, but model of testing for this code isn't clear for now.
- Test procedures row set. That is: in MySQL stored procedures, you can do
SELECT
statements right in it's code. This will cause immediate sending te row set to the client. So, some of procedures may "return" those row sets. By definition, it is impossible to "select" something "from procedure" - because there may be many row sets. To overcome this, you may replace plainSELECT
to insertions into temporary table. Then you'll be able to operate on row set with querying that table. - Test the entities, inaccessible due to permissions reasons. It's obvious - you'll be able to test only those items, which are accessible for user, invoking testing API.
On Tested Expressions
In addition to limitations on tested entities, there are also some things, which can not be tested in expressions:
- Expressions-queries, which return more than one row. Row sets are not possible to test within single expression, and, if it is the intention, you should test each row in a separate test-case.
- Expressions that cause syntax errors. Since mysql-unit is using prepared statements under the hood, it won't be possible to prepare them from syntax-invalid queries. There is nothing you can do to overcome that, so - use correct syntax in your test-cases.