I'm going to be counter intuitive: don't mock your database, don't use any other database systems than the one you're going to use in production.
If you mock your database you're probably going to find out about actual problems with how you structured your models and data only in production which is not great :D
You can maybe use fixtures to prepopulate the test DB to speed up things a little bit but each test should run in isolation. As Alex said the testing time will probably increase a little bit but it shouldn't that much because you're not using a RDBMS.
So, populate the db, run the test, clean the db, repeat.
I'm going to be counter intuitive: don't mock your database, don't use any other database systems than the one you're going to use in production.
If you mock your database you're probably going to find out about actual problems with how you structured your models and data only in production which is not great :D
You can maybe use fixtures to prepopulate the test DB to speed up things a little bit but each test should run in isolation. As Alex said the testing time will probably increase a little bit but it shouldn't that much because you're not using a RDBMS.
So, populate the db, run the test, clean the db, repeat.
That makes sense. So mocking is not required after all? Thanks!
I would start thinking about mocking parts of the database only if the tests are extremely slow :-)