When you start testing, it's often hard to decide what logic you want to test and what logic you don't want to test. Reasons for this could include certain logic being too trivial, too hard, or just not important enough to test. This statement implies that you do not have to test absolutely every line of code in your app and that is intentional. Sometimes it's simply not reasonable to write tests for a certain part of your code. For instance, you don't have to test that UIKit behaves as it should; it's Apple's job to make sure that the frameworks they ship are bug-free.

Determining what to test is important, and the longer you defer deciding whether you will add tests for a particular piece of logic, the harder it will be to write tests for it. A simple rule of thumb is that you don't need to test Apple's frameworks. It's safe to assume that Apple makes sure that any code they ship is tested and if it contains bugs, there's not much you can do to fix it anyway. Moreover, you don't want your tests to fail where Apple's tests should have.

What you should at least test is the call-site of your methods, structs, and classes. You can think of the call-site as the methods that other objects use to perform tasks. It's a good practice to make anything that's not used by the call-site of your objects private, meaning that outside code can't access that part of the code. More on this later when you learn more about refactoring code to make it more testable.

You should also test code that you might consider too trivial to write tests for. These parts of your code are likely to receive the too trivial treatment in other parts of the development process too. This usually causes you and your coworkers to pay less and less attention to this trivial piece of code, and before you know it, a bug gets introduced that might not be spotted until the app is in the App Store. Writing trivial tests for trivial code takes very little time and saves you from minor oversights that could lead to massive complications.

A few simple guidelines that you should follow when you write tests are:

Test trivial code; this usually requires minimal effort.
Test the call-site of your objects; these tests will ensure that your public APIs are consistent and work as expected.
Don't test Apple's frameworks or any other dependencies; doing this is the responsibility of the framework vendor.

Once you've determined what you should test, it's time to start writing the actual tests. However, if you've heard about testing before, you might have heard of terms such as integration tests, unit tests, sanity tests, and a couple of others. The next segment explains a couple of the most important and well-known types of testing.