Damned if you do, damned if you don't
If you don't allow the test system to be as fully customisable as the live system -- especially if it uses the database to store the style information -- then your test isn't realistic enough. A namespace clash could result in odd things happening if, for instance, you changed a font or colour while a record was displayed on screen then saved that record -- only now it was corrupted with the colour or font in one of the data fields, but it will only appear there when that record is next read from the database.
This is only ever going to show up on a test with real, live users, because they usually underestimate how delicately to treat anything.
My current favourite method (I'm working on a database-backed web app right now) is to have one script that determines whether to use the real or fake data by means of regular expression matches on the URL by which it was invoked. That way, the obvious indicator is in the browser's address bar; and I only have to worry about it not 500-ing, not about keeping two copies almost identical save for a single include statement. (And, yes, I've missed it, and ended up doing an UPDATE on a record that wasn't there when a user saved a record they had loaded just before I overwrote the script with a new version that was still working on the wrong database. But that's what we have a general log for. If you add up all the CPU cycles that have been spent on logging over the years, it's nothing compared to the effort that might otherwise have been necessary).
Also, MariaDB in Ubuntu's default configuration includes the name of the current database in the prompt. When you have two databases with identical table names and structures, this is a definite improvement over MySQL.
Biting the hand that feeds IT
