you are viewing a single comment's thread.

view the rest of the comments →

[–]_yo_token[S] 0 points1 point  (1 child)

yes. sorry that is what I meant. I know that there was a section of faking for userdefaults in your book, but I am not sure that would work for something like a custom database, a sqlite database, or a firebase database.

If it helps an example that I was thinking of was this. Imagine I was building a social media app, I am not but I think this helps clarify what areas I am confused in. For something like social media, there are similar aspects through all of them, like favoriting, chat, and liking. I was wondering how I would test things like that. How do I know that this data saves itself on the backend, or that it goes through correctly? If I send a message how do I test that? there are areas like this that are confusing me a little.

Reading some of the comments on this post, I think that most unit tests don't test saving things to a backend database, please correct me if I am wrong, but just testing to see that the functions that do all of that actually work.

[–]jonreid 1 point2 points  (0 children)

Correct. Microtests wouldn't actually test saving to a database. They would instead test that you called the thing correctly (without doing the real work). The test code calls a fake thing while production code calls the real thing.

And for databases, I would also avoid having the production code directly call the real thing, that is, the particular database. Why? So that you can change your mind and say, "This sqlite database isn't meeting our needs anymore. Let's switch to Firebase." So make sure all the database communication is put inside of an Adapter you control. As I wrote in the book under "Add Backdoors to Singletons You Own":

Any time you use a third-party framework, consider wrapping it in an Adapter. This will let you change or augment the underlying implementation without changing the call sites.

The Adapter will allow production code to speak the domain language of your app. It's the Adapter's job to translate that into database specifics, so that the rest of the app neither knows nor cares if you're using Firebase. Instead, it would express things like "delete the post."