> You know what is just as easy? Making SQLite databases (aka files) for each test case.
By doing this, you're breaking the dev-prod parity rule of 12factor apps [0]: you should make sure your dev and prod differ as little as possible. If you're using MySQL in production, you should also use it in dev.
Let's not conflate unit testing with integration testing. SQLite should, in most cases, work just fine for unit testing.
First off, many people would argue unit testing should never really require a database. I'm not of that opinion, but I'm not writing CRUD apps, and since there's not really a SQL unit testing framework, using SQLite is a nice compromise, especially as unit testing should necessarily be limited in scope.
Integration testing should definitely be done on a system that is in parity with prod.
By doing this, you're breaking the dev-prod parity rule of 12factor apps [0]: you should make sure your dev and prod differ as little as possible. If you're using MySQL in production, you should also use it in dev.
[0] http://12factor.net/dev-prod-parity