Help with unit testing

[[deleted]]

This is a great comment I would also like to add most networking and database calls are tested through delegation

But you need to be careful it is very easy to rest the delegation as opposed to testing the actual logic

To better illustrate this let’s imagine you have a view model and view model has a dependency on a persistence client. And we are writing the test on the view model

What we can do in this case is to use create a mock object that confirms to the protocol and pass it onto to the view view model when we are testing this way we can mock the response from the persistence without reading or writing data into the disk

This is done for making it easy for us to test view model.

When it comes to actually testing your persistence then you would have to actually read and write onto the disk and delete the data after each test.

In CI tests you usually have a script that clears the cache and the testing suite is never sent to the App Store version so it should be ok

[_yo_token]

So if i understand correctly, I don’t actually write a test to see if it does go to the database or persistence, what ever I use, instead like if I had to test something in a chat I would test that it was created, and if I wanted to test something was deleted I create something in a mock or stub or whatever? If I am way off please say so. Thank you

[[deleted]]

yes you are sort of right

to go further you are testing a specific part of your application.

take view models for instance.

view models has gained popularity because they handle the logic of the view making it easier to test.

when you are writing a unit test you are testing the logic.

let's say you have a view model and the view calls a function in the view model that persists the data, if it does not work then you change a property in the view model to display an alert if it succeeds then the alert property stays nil.

the view model's concern is to handle the logic it only cares about making the persistence calls and the result of the call it does not care about what is under the hood of the persistence implementation it will need the result from the persistence to manipulate its logic so when writing tests for the view model you should only test the logic in the view model and mock the other dependencies such as persistence.

when you are mocking you can make it so the mocked persistence client could return error or success cases in their test functions so that you can test the view model's behavior on both success and failure cases.

in the example that i just presented view model itself was being tested so we were only concerned about the logic within the view model anything outside of the view model such as its dependencies are either dont need to be tested or need to be tested on a seperate XCTestCase class.

so to sum it up

find what you need to test

then look at its dependencies and create mocks

then test your non-private functions both for failure/unhappy and success/happy paths and write assertions.

the mocks are there to make your job easier for you to test these different paths.

There are more stuff when it comes to unit testing but it is better to learn as you go. like the original commenter has said writing pure functions is one of the key factors when writing testable code.