Single responsibility is also why I prefer to use a dedicated delegate for navigation only, even if the view controller already has a delegate. With a NavigationDelegate they have one less thing to do. View controllers are the glue code of iOS applications they end up doing a lot of things. Remember the definition of the single responsibility principle? An object should only have one reason to change. Making the navigation side of your view controllers easier to test this way comes with other benefits too.īecause your view controllers are now unaware of how to present new view controllers, they won't need to change when updating the way navigation works (see this PR in the example project). Once the delegate is in the codebase, you can come back to it later and extract the implementation in a dedicated object. This is definitely not something I would endorse in the long run, but it might help you get started. To get started and make your code testable you can even have the view controller be its own navigation delegate. You can start using NavigationDelegates today. In fact, it fits well with most architectures. You don't have to change your application architecture to adopt it. What I love about this idea is that it is cheap and portable. func testCallsShowRedWhenRedButtonTouched() You can adopt NavigationDelegates today To test that a view controller triggers the expected navigation you can verify that it calls the appropriate method of its NavigationDelegate. With a NavigationDelegate in place, testing how a view controller does navigations is now a matter of testing how it interacts with its delegate. I like to call this kind of delegates NavigationDelegates *. View controllers should only trigger the navigation and then delegate the act of performing it to another object. The key to make navigations between view controllers easy to test lies in appreciating that view controllers be responsible for presenting other view controllers. You can use a simple and cheap pattern to easily test how your view controllers trigger navigation, making your code easier to work with in the process. Those and other little gotchas make the tests harder to write and reason about, but it doesn't have to be so. There are usually animations involved, which in turn require either your test assertions to be asynchronous or your code to allow the animated flag to be injected as false from the tests. You need to wrap your view controller under test in a UINavigationController if you want to test a push navigation or add it to a UIWindow if for a modal presentation. Testing navigation between view controllers can be tricky. Here's a question that often comes up when testing iOS application: "How can I test that a view controller presents another view controller when something happens?"
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |