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 implies that you do not have to test absolutely everything your app does, 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 UIKit is bug-free.
Determining what to test is important, and the longer you defer deciding whether you will add tests for a certain piece of logic, the harder it will become 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 own 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. The call-site is defined here as the methods that other objects use to perform tasks. It's actually good practice to make anything that's not on the call-site of your objects private, meaning that outside code can't access that part of the code. We'll look more into that later when we refactor code to be 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 approach in other aspects of the process as well. This leads to you and your coworkers paying less and less attention to this trivial piece of code and before you know it, a bug is introduced that you might not catch until your app is in the App Store. Writing trivial tests for trivial code takes very little time and saves you from minor oversights leading to large complications.
So, to sum up, a few simple guidelines that you might want to follow when you're writing tests are:
- Test trivial code; minimal effort is involved
- Test the call-site of your objects; they will make sure 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're going to 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 will focus on a couple of the most important and well-known types of testing.