I'm running tests from the same database as I use in development. I recall using Rails and I used a separate database for testing (mainly coz the tutorial I was going by said so). Made sense though. I was wondering it this was the common way to do things or whether there was an alternative. Can anyone shed a little light on this?
Quite common, but… it is a result of misusing PHPUnit
It is important to distinguish unit-tests from integration-tests and acceptance-tests.
The main aim of PHPUnit is writing unit-tests.
Unit test is supposed to test isolated "units" (functions, public methods). Everything else, including database, is emulated via Test Doubles (Mocks). So, if you need to test method of your controller you "mock" model classes so that they return pre-defined (or randomly generated) answers. If you need to test the model you mock db-access classes and, taking this to the extreme, if you need to test db-driver you mock the socket-layer to return specific byte-sequences.
On the other hand it is possible to use PHPUnit for acceptance-tests (though, there are better tools for that). Acceptance tests in web-applications are supposed to fake web-requests and check that application returns proper responses. It is very desirable to check the full-stack, so, requests should hit database eventually. In this case it is a good idea to use a separate database, so that tests do not harm production data.
I used to (not in PHP admittedly, but this applies to every DB) test stored procedures on the dev DB.
DBs have transactions. So start one, truncate tables, insert test data, run tests and then rollback. Your DB will be back to its old state. Simple.