I am writing unit tests for my SwiftData application. Currently, I am using in-memory database, which get reset after every test. What benefits will I gain if I start using real database? My main reason is that real database (SQLite) will be the environment user will experience. I can easily wipe out the records from the real database after each test is completed.
Are there are scenario where running in-memory test will produce a different result as compared to running the test with real database? Am I ignoring and not capturing those scenarios by running it in-memory?
PS: I used the term unit tests. You can use integration test if that makes you feel better :)
1 Answer 1
One thing a "real database" does that an in memory database doesn't do is talk to other programs. A database often ends up being what we call "shared mutable state". That can easily result in a scenario that will produce a different result.
The in memory DB can do exactly the same thing of course. Provided something else knows about it and talks to it.
Testing the timing issues at work here is very difficult. So unless your tests are targeted at exactly those issues you're probably fine running your tests against an in memory DB. So long as they are functionally equivalent.
-
Thanks! The tests are run against the SQLite database only available on the device. It is a private database.user19037628– user190376282024年04月16日 15:57:06 +00:00Commented Apr 16, 2024 at 15:57
-
@user19037628 many devs start out thinking their app will be the only one to talk to the DB. Then the world changes. If you're going to design this expecting that make that assumption clear somewhere.candied_orange– candied_orange2024年04月16日 16:00:08 +00:00Commented Apr 16, 2024 at 16:00
-
The app is using SwiftData. SwiftData uses Sqlite database. And syncing to iCloud is not supported.user19037628– user190376282024年04月16日 16:01:43 +00:00Commented Apr 16, 2024 at 16:01
:memory:
file instead of a real file path, which makes it really easy to integrate in tests.