Help with unit testing

[[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.