> I don't. I use sqlite for unit and local integration testing, and aurora-mysql for production.

That's a recipe for tests that don't catch edge cases.

Unit testing code that touches the database is not useful, and in fact it indicates there is likely a design flaw. Code that acquires from or changes data in the DB should be self contained.

An integration test that doesn't use the same DB as production is unsatisfactory.

Using a DB inside your unit tests is an antipattern and arguably a violation of the concept of a unit test in the first place.

Integration tests should run against a test environment, otherwise, what integration are you testing? I don't see the value in writing integration tests that test the integration between my code and a one-off integration test DB that exists solely for the purpose of integration testing.

There is no syntactical difference between Aurora/MySQL and regular MySQL until you start interacting with S3.

Also if you’re using only the subset of MySQL that is supported by SQLite, you’re missing out on some real optimizations for bulk data loads like “insert into ignore...” and “insert...on duplicate key update...”. Besides that, the behavior of certain queries/data types/constraints are inconsistent between MySQL and every other database in existence.

Finally, you can’t really do performance testing across databases.

> As a side note, I quite literally can't use aurora-mysql for local unit and integration testing. It doesn't exist outside AWS.

You can use mysql though...

> Do you use the same database engine for your unit and integration testing as you do production? I don't. I use sqlite for unit and local integration testing, and aurora-mysql for production.

Yeah, don't do that.