Menu
When do you test against an In-Memory Database vs. a Development Database?
Also, as a related side question, when you do use a Development Database, do you use an Individual Development Database, an Integration Development Database, or both?
Also++, for unit testing, when do you use an In-Memory Database over mocking out your Repository/DAL, etc.?
996
In-memory databases can persist data on disks by storing each operation in a log or by taking snapshots. In-memory databases are ideal for applications that require microsecond response times or have large spikes in traffic such as gaming leaderboards, session stores, and real-time analytics.
An in-memory database is useful for both unit tests and integration tests when you don't want to mock out a complete data access layer, or if you need to have a real database due to an ORM.
SQLite Database SQLite is a SQL database that runs only in embedded mode, either in memory or saved as a file.
In-memory databases are faster than traditional databases because they require fewer CPU instructions. They also eliminate the time it takes to access data from a disk. In-memory databases are more volatile than traditional databases because data is lost when there is a loss of power or the computer's RAM crashes.
In memory is an excellent choice for your unit-tests, when the data is easy to seed for your given test cases and a very particular operation is being tested. A real database is better for integration tests, where the data pre-requisites are more complex and there is value to having the base data remain after the tests complete.
For us, the only things we allow in our 'fast' test suite of JUnit tests are those that do not have any external dependencies (database, file, network, etc) so that the suite can be run quickly and efficiently by both developers and continuous integration on checkin. If there is a certain test that absolutely needs to go to the DB, then an in memory one is the only way to go.
A couple points to keep in mind:
As for your other question, it really depends on your need. A good rule of thumb is one development database per code branch, since schema changes may be needed that are not relevant to another branch of code. Just having a dedicated development database is important; I'm surprised at how many development teams have to share a database with the QA team, etc. It is important to be able to make changes in a sandboxed environment that does not affect other teams or prevent others from doing their work, so if you've met those requirements you're doing well.
78
For my team, it's in-memory on developper machine, and the real-database on the continuous integration server.
20
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
