[batbomb]

> Oracle abomination

Okay... PostgreSQL is great but it still has a bit of catching up to do.

> ... run your MySQL

Wait, Oracle is an abomination but MySQL is okay?

> Before each test case, we do BEGIN TRANSACTION, and at the end of the case, we do ROLLBACK TRANSACTION. This is crazy fast, so there's no setup penalty.

You know what is just as easy? Making SQLite databases (aka files) for each test case. Copy a file, open it, delete it. It has the added benefit of allowing you to actually commit changes and not worry about rollback. There are some compatibility issues, and I'm not familiar with all those issues in a Rails context.

[rakoo]

> 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.

[0] http://12factor.net/dev-prod-parity

[batbomb]

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.

[jeffdavis]

"Wait, Oracle is an abomination but MySQL is okay?"

I think he was referring to administrative challenges and setup/startup overhead, not steady-state performance.