We have now shown that previews are not inhibited whatsoever by SQLiteData. All of our feature code works in previews, and SQLiteData has even gone above and beyond to make sure that even some advanced functionality works in previews, such as record sharing.

The same cannot be said of other persistence frameworks out there. Large 3rd party libraries such as Firebase are notorious for putting strain on Xcode’s ability to preview SwiftUI views, and many times people have no choice but to define those little inert views and extract them to a separate package just so that they can get some preview coverage on them.

Now let’s turn our attention to unit tests, which are closely related to previews. Unit tests require that we be able to run our app’s features in complete isolation. Isolation means that the code won’t be running on a simulator or actual device, and so the code paths we are testing can’t ever access the real life APIs that interact with the device. Isolation also means that the code paths we execute during tests should not reach out to the outside world to get data because we most likely will not be able to assert on what that data is in the test.

This can be surprisingly tricky to get right, but SQLiteData’s SyncEngine has most of the hard work taken care of for you. Each of your tests can use a sync engine that is fully isolated from not only the outside world, but also from every other test running in parallel. This means we can write tests much like we would normally without even thinking about the sync engine, and if we need to test something sync engine specific, like the iCloud sharing behavior, then we have that tool available to us via our mocks.

Let’s take a look at how this works.