XUnit testing - InMemory vs Real Database

Viewed 218

I am struggling to decide on the best approach for using my database in my unit tests. I am using XUnit for the tests and my database model is code first with entity framework.

The options I have are InMemory and Real Database, both scaffolded by the entity framework context.

Both seem to have issues though -

InMemory - Good because it can spin up database instances and destroy them fast in memory. Bad because it doesn't find native SQL bugs and can't test functions that run raw sql commands.

Real - Good because it can find native SQL bugs and test functions that run raw sql commands. Bad because DbContext is not thread safe and and xunit runs tests asyncronously which means I would need to spin up a new real database for each test (timely, and messy).

Which is the preferred solution here? Both seem to have pros and cons,i s there a best solution here I am missing?

1 Answers

I recommend the pyramid approach. At the bottom of the pyramid are unit tests, they are numerous and your quickest way to get any feedback on code you just wrote. On top of that, are your integration tests, which are far fewer. Then, on top of that are full regression tests then smoke tests, with each slice of the pyramid getting smaller.

Having said all this, why not both? Think of InMemory as unit tests, and Real as integration tests.

At the very least I recommend unit tests with an InMemory database. Yes, unit tests are isolated and do not catch all the bugs but the benefit here is you now have a solid testing foundation to build upon. Unit testing can also run as part your build, and if someone happens to break something by accident this will catch it like a safety net.

Related