Actions

Talk

Developer Area/Testing/Unit Testing

From Mahara Wiki

Revision as of 09:04, 7 September 2011 by Andrewnicols (talk | contribs) (Thoughts, etc on the implementation of phpunit testing)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Just some issues I've come across when rebasing, updating, etc the unit test branch which will need consideration for when we integrate with Jenkins

Databases

Just a note to say that we should probably test both MySQL and PostgreSQL

Require Installation

Due to the way that init.php works, to run the unit tests, a completed installation is required. This must also be up to date. We need to consider how we're going to do this. My initial thought is to:

  • Create a CLI installer (very easy to do as the unit test work has done the groundwork for this) - this is also really handy more generally
  • Create a new database for each patch going through gerrit and use the CLI installer to install the main mahara
  • Set the admin password ;)
  • Then run the unit tests
  • At the end, drop the database

This has the benefit that we test the full installation - if mahara cannot be installed (at least through the CLI), we need to know! It also has the benefit that we don't leave stale testing tables around. We drop all tables between unit tests, and if tests are interrupted mid-way through, then the test tables may not be fully removed. Unfortunately, some components cannot be uninstalled in a transaction. This is rare, but I have seen it happen. Once this happens, the unit tests fail to either install, or clean the stale tables and re-install. As a result, all future unit tests are then broken. This also ensures that we can run multiple tests simultaneously. The current implemtation of the unit tests replaced the current db prefix with tst_ so multiple tests in the same database will also fail

Testing Database Upgrades

At present, database upgrades are not tested. I think that this is not within the scope of the initial unit test functionality, but should not be forgotten. Where the version number (or any plugin's version number) has changed (and possibly in other scenarios too) we need to install the previous commit, then check out the current commit, and then test an upgrade. Again, this should be done for both PostgreSQL and MySQL