[WIP] Add support to UINavigationController

[barbosa]

This is still a work in progress.

Its idea is to have a similar implementation of the verifier for UINavigationControllers.

Tasks are listed below:

• create structure with STGNavigationControllerVerifier and UINavigationController category
• swizzle pushViewController:animated:
• swizzle popViewControllerAnimated:
• swizzle popToRootViewControllerAnimated:
• swizzle popToViewController:animated:
• swizzle setViewControllers:animated:
• update documentation

[codecov-io]

Current coverage is 98.27% (diff: 97.54%)

Merging #2 into master will decrease coverage by 1.72%

@@           master         #2   diff @@
========================================
  Files           2          5     +3   
  Lines          56        174   +118   
  Methods         0          0          
  Messages        0          0          
  Branches        0          0          
========================================
+ Hits           56        171   +115   
- Misses          0          3     +3   
  Partials        0          0          

Powered by Codecov. Last update 4a300a2...66a1f6f

[marcelofabri]

shouldn't these methods return the view controller that would be popped? It's not a big issue since I've never seen any code using the return code, but who knows ¯_(ツ)_/¯

[barbosa]

Yeah, I thought about that. Wasn't sure if necessary. But it makes sense. I'll do it.

[marcelofabri]

I know that it's not probably the main use case in unit tests, but what if there's more than one navigation controller? Should we have a property in STGNavigationControllerVerifier that can be used to test which navigation controller was used?

I also thought about init'ing it with a UINavigationController, so only changes to that object would be reflected in the verifier, but I think this might turn it harder to use, because you may not have a reference to the navigation controller in the unit tests (and you'd have to refactor your app to get it).

[marcelofabri]

(nullable UIViewController *) instead?

[barbosa]

You mean (nonnull UIViewController *)?

[marcelofabri]

Yeah 😅

[barbosa]

Code coverage went down due to the new return statements. I'll add some unit tests to cover it.

[barbosa]

Hey @marcelofabri,

I've finally had some time to have a look at it again.

Based on your comment...

shouldn't these methods return the view controller that would be popped? It's not a big issue since I've never seen any code using the return code, but who knows ¯_(ツ)_/¯

... I was thinking:

Although we swizzle the implementations to send all the notifications we need and capture them, we don't follow the real implementation of the methods. Eg.:

- (void)stg_pushViewController:(UIViewController *)viewControllerToPush
                      animated:(BOOL)flag {
    NSNotificationCenter *nc = [NSNotificationCenter defaultCenter];
    [nc postNotificationName:STGViewControllerWasPushedNotificationName
                      object:viewControllerToPush
                    userInfo:@{STGViewControllerPushingAnimatedKey: @(flag)}];
}

In the case above, we're just posting the notification but we're not including the given viewController onto the navigation stack. The same logic applies to present/dismiss.

Because of that, methods returning viewControllers as part of the pop action, would have to know which viewControllers are already in the stack so it can pop the last one.

Maybe if we just ignore those values, returning nil or @[], we could make this easier to implement. I don't see this as a problem given that the main purpose of the library is to test the navigation behavior (which we are already doing through a verifier).

This would allow me to remove the if statement from some methods, bringing the coverage back to 100%.

Thoughts?

[marcelofabri]

@barbosa Sorry for taking so long, but I agree we can just return nil and @[], documenting that. Also verifying that in tests to make it clear that it's the intended behavior.