What to test
What should be tested? When using TDD and following the rules mentioned in the previous sections, the answer is easy—everything. You only write code because there is a failing test.
In practice, it's not that easy. For example, should the position and color of a button be tested? Should the view hierarchy be tested? Probably not. The color and exact position of the button are not important for the functioning of an app. In the early stages of development, these kind of things tend to change. With Auto Layout and different localizations of the app, the exact position of buttons and labels depend on many parameters.
In general, you should test the features that make the app useful for a user and those that need to work. The user doesn't care whether the button is exactly 20 points from the rightmost edge of the screen. All the user is interested in is that the button does what they expect it to and the app looks good.
In addition to this, you should not test the whole application in total using unit tests. Unit tests are meant to test small units of computation. They need to be fast and reliable. Things, such as database access and networking, should be tested using integration tests, where the tests drive the real finished application. Integration tests are allowed to be slow because they are run a lot less often than unit tests. Usually, they are run at the end of the development before the application is released, or they are run with the help of a continues integration system each night on a server where it doesn't matter that the complete test suite takes several minutes to execute.
