iOS: The One Weird Trick For Testing View Controllers in Swift

Posted on August 2nd, 2015

I’ve been testing View Controllers in Swift for the past year, but for some reason, last week all my tests would just randomly start failing due to some type of timer / race condition issues. Turns out, I was setting up my View Controller tests incorrectly:

import UIKit
import XCTest
@testable import MyProject

class ViewControllerTests: XCTestCase {
    
    var viewController: ViewController!
    
    override func setUp() {
        super.setUp()
        
        let storyboard = UIStoryboard(name: "Main",
            bundle: NSBundle.mainBundle())
        let navigationController = storyboard.instantiateInitialViewController() as! UINavigationController
        viewController = navigationController.topViewController as! ViewController
        
        UIApplication.sharedApplication().keyWindow!.rootViewController = viewController

        // this is the line responsible for the race condition
        NSRunLoop.mainRunLoop().runUntilDate(NSDate()) 
    }

    // tests here
}

import UIKit

import XCTest

@testable import MyProject

class ViewControllerTests: XCTestCase {

var viewController: ViewController!

override func setUp() {

super.setUp()

let storyboard = UIStoryboard(name: "Main",

bundle: NSBundle.mainBundle())

let navigationController = storyboard.instantiateInitialViewController() as! UINavigationController

viewController = navigationController.topViewController as! ViewController

UIApplication.sharedApplication().keyWindow!.rootViewController = viewController

// this is the line responsible for the race condition

NSRunLoop.mainRunLoop().runUntilDate(NSDate())

}

// tests here

}

The problem was clearly with the last line in my setup NSRunLoop.mainRunLoop().runUntilDate(NSDate()) . Since the goal here is to make sure that the UIViewController life cycle functions – including viewDidLoad and viewDidAppear – get called correctly, I replaced this line with viewController.loadView(). I ran into the same frustrating issue.

So after googling around, I found an amazing presentation from the testing expert @modocache: Everything You (N)ever Wanted to Know about Testing View Controllers . Go ahead and flip though it. I’ll wait!

Instead of using NSRunLoop.mainRunLoop().runUntilDate(NSDate()) or viewController.loadView(), the key is to use let _ = viewController.view like this:

    override func setUp() {
        super.setUp()
        
        let storyboard = UIStoryboard(name: "Main",
            bundle: NSBundle.mainBundle())
        let navigationController = storyboard.instantiateInitialViewController() as! UINavigationController
        viewController = navigationController.topViewController as! ViewController
        
        UIApplication.sharedApplication().keyWindow!.rootViewController = viewController
        
        // The One Weird Trick!
        let _ = navigationController.view
        let _ = viewController.view
    }

override func setUp() {

super.setUp()

let storyboard = UIStoryboard(name: "Main",

bundle: NSBundle.mainBundle())

let navigationController = storyboard.instantiateInitialViewController() as! UINavigationController

viewController = navigationController.topViewController as! ViewController

UIApplication.sharedApplication().keyWindow!.rootViewController = viewController

// The One Weird Trick!

let _ = navigationController.view

let _ = viewController.view

}

I’ll be honest and be the first to admit that this is not a solution I would have naturally come up with ever. After discussing it with @allonsykraken, I kind of understand why it works.

The key here is that Apple overrides the viewController’s view getter to call the loadView function and do a bunch of other things we have no access to. If anyone else has other great insights into why this works, feel free to add it in the comments!

I went ahead and updated my other blog posts on View Controller testing if you’re interested in learning more:

UPDATE: As Tomasz Szulc points out below in the comments, Apple has a whole explanation in the documentation about why you shouldn’t call loadView():

You should never call this method directly. The view controller calls this method when its view property is requested but is currently nil. This method loads or creates a view and assigns it to the view property.

If the view controller has an associated nib file, this method loads the view from the nib file. A view controller has an associated nib file if the nibName property returns a non-nil value, which occurs if the view controller was instantiated from a storyboard, if you explicitly assigned it a nib file using the initWithNibName:bundle: method, or if iOS finds a nib file in the app bundle with a name based on the view controller’s class name. If the view controller does not have an associated nib file, this method creates a plain UIView object instead.

If you use Interface Builder to create your views and initialize the view controller, you must not override this method.

You can override this method in order to create your views manually. If you choose to do so, assign the root view of your view hierarchy to the view property. The views you create should be unique instances and should not be shared with any other view controller object. Your custom implementation of this method should not call super.

If you want to perform any additional initialization of your views, do so in the viewDidLoad method.

UPDATE 2: I really like @salutis‘s suggestion on making this a lot more readable:

@NatashaTheRobot Readability tip: Make a UIViewController extension with “preloadView()” method that does just “_ = view”.

— Rudolf Adamkovič (@salutis) August 2, 2015

Here is what the code would look like:

// UIViewController+Extension
extension UIViewController {
    
    func preloadView() {
        let _ = view
    }
}

// UIViewController+Extension

extension UIViewController {

func preloadView() {

let _ = view

}

        // Your Test File

        let storyboard = UIStoryboard(name: "Main",
            bundle: NSBundle.mainBundle())
        let navigationController = storyboard.instantiateInitialViewController() as! UINavigationController
        viewController = navigationController.topViewController as! ViewController
        
        UIApplication.sharedApplication().keyWindow!.rootViewController = viewController
        
        // Using the preloadView() extension method
        navigationController.preloadView()
        viewController.preloadView()

// Your Test File

let storyboard = UIStoryboard(name: "Main",

bundle: NSBundle.mainBundle())

let navigationController = storyboard.instantiateInitialViewController() as! UINavigationController

viewController = navigationController.topViewController as! ViewController

UIApplication.sharedApplication().keyWindow!.rootViewController = viewController

// Using the preloadView() extension method

navigationController.preloadView()

viewController.preloadView()

UPDATE 3: (This is the reason I love blogging. Learning so much right now!) Another great Swift tip from @jckarter that I didn’t know about!

@NatashaTheRobot @salutis The let isn't necessary. You can also just assign '_ = thingToIgnore'

— Joe Groff (@jckarter) August 2, 2015

So your extension can now be even prettier like this:

// UIViewController+Extension
extension UIViewController {
    
    func preloadView() {
        _ = view
    }
}

// UIViewController+Extension

extension UIViewController {

func preloadView() {

_ = view

}

UPDATE 4: @joemasilotti has a less hacky solution to loading the view!

@NatashaTheRobot @modocache @allonsykraken plain old Obj-C: XCTAssertNotNil(controller.view);

— Joe Masilotti (@joemasilotti) August 2, 2015

        super.setUp()
        
        let storyboard = UIStoryboard(name: "Main",
            bundle: NSBundle.mainBundle())
        let navigationController = storyboard.instantiateInitialViewController() as! UINavigationController
        viewController = navigationController.topViewController as! ViewController
        
        UIApplication.sharedApplication().keyWindow!.rootViewController = viewController
        
        // Test and Load the View at the Same Time!
        XCTAssertNotNil(navigationController.view)
        XCTAssertNotNil(viewController.view)

super.setUp()

let storyboard = UIStoryboard(name: "Main",

bundle: NSBundle.mainBundle())

let navigationController = storyboard.instantiateInitialViewController() as! UINavigationController

viewController = navigationController.topViewController as! ViewController

UIApplication.sharedApplication().keyWindow!.rootViewController = viewController

// Test and Load the View at the Same Time!

XCTAssertNotNil(navigationController.view)

XCTAssertNotNil(viewController.view)

Enjoy the article? Join over 20,000+ Swift developers and enthusiasts who get my weekly updates.

Dima Pilipenko

no variable “let _ = ” declaration needed, to call loadView()
- ketzusaka
  
  She said in the post she tried that and it didn’t do what was needed
Tomasz Szulc

You tried with loadView(). I just wanted to say that you should never call loadView() method directly. This is ugly hack. Apple does not recommend it. https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIViewController_Class/#//apple_ref/occ/instm/UIViewController/loadView.

I think accessing view property is the best solution because it starts entire flow of loading view from storyboard (actually from nib file that is created by Xcode internally) and configuring view including setting constraints and calling viewWillAppear and viewDidAppear of view controller by default.
- Natasha Murashev
  
  Thanks! Didn’t realize they said this in the documentation. Will add as an update.
Scott Berrevoets

Note that iOS 9 introduces loadViewIfNeeded() on UIViewController. The documentation is pretty minimal on that for now, but it looks like that’s OK to call directly.
- Natasha Murashev
  
  For testing, I want to make sure the view is loaded – it’s mandatory for all my tests. Do you know if loadViewIfNeeded() will load it in the testing scenario I discuss above?
  - Tomasz Szulc
    
    Natasha, I see loadViewIfNeeded() do the same calls as accessing view directly. Accessing view does not call loadViewIfNeeded() but both accessing view and loadViewIfNeeded() call first loadViewIfRequired(), so it should be safe to call loadViewIfNeeded() then.
  - Scott Berrevoets
    
    I think loadViewIfNeeded() was created so that you don’t have to use .view to just load the view, even if you didn’t need it. Objective-C has a warning for that (“using getter as side effect” or something along those lines), so this is a cleaner way of ensuring the view is loaded.
- Tomasz Szulc
  
  Could you share some link with documentation about the method? I cannot find any. Or minimal means that there is no documentation at all? :>
  - Scott Berrevoets
    
    Minimal in this case means there is a comment in the header file that says “Loads the view controller’s view if it has not already been set.”
    
    That’s all I could find on it.
    - Tomasz Szulc
      
      Ah, yeah, I found it too. Thanks.
orta

I’ve always relied on using the begin/end appearance transitions to ensure all the hierarchy + view controller set up is done correctly.

https://github.com/artsy/eigen/blob/master/Artsy_Tests/Extensions/UIViewController+PresentWithFrame.m#L20-L22
- Tomasz Szulc
  
  It does the same thing like accessing view or loadViewIfNeeded() but from different side. It calls viewWillAppear(_:) first and then loadViewIfRequired(). IMO loadViewIfNeeded() is the best approach for now. The loadViewIfNeeded() calls viewWillAppear(_:) later in its flow.
  - orta
    
    I appreciate the feedback, but I see nothing in the iOS9 documentation about this function. The appearance methods are the way that apple have been recommending that we deal with the viewDid/WillXXX functions in their docs. This really is the way to ensure you get it set up like you would in you app.
    - Tomasz Szulc
      
      I’ve double checked it and you’re right. your approach might be better in testing.
      
      I’ve run the code in applicationDidFinishLaunchingWithOptions method and the flow was almost the same for every way I loaded the view. When I moved the code into tests and do not assigned the view controller to any window it behaves differently.
      
      – Accessing view and calling loadViewIfNeeded() finished its flow on viewDidLoad() method.
      – Your approach allowed the view controller to call private __viewWillAppear() method at the beginning of the flow and then view was loaded and set and viewDidLoad(), viewWillAppear() and viewDidAppear() have been called. So your flow is more complete than the previous in testing.
      Thanks for this!
    - Mouhcine El Amine
      
      Hey @orta:disqus ,
      Thanks for the great tip! (the link is outdated as you changed the file names)
      Are there some docs from Apple except from the “beginAppearancetransition” documentation in UIViewController class reference?
Pingback: iOS: UIViewController’s view loading process demystified : Tomasz Szulc()
James

Hi Natasha, thanks for the informative post. I had come across similar issues before aswell and here were the results of my findings.
http://stackoverflow.com/questions/28733016/view-controller-tdd
Alex Chechel

Thank for blog
I try repeat test viewController but have error. How Can I fix that?
- Любомир Маринов
  
  Is your Storyboard initial view controller of type UINavigationController? Because the explicitly unwrapped variable seems to return ‘nil’. Try unwrapping with ‘if let …’ and check if the code in the closure executes.
  
  p.s. 9 months later ….. damn, I feel like a spammer 😀
Ethan Sherr

“Apple hates developer who came up with this One Weird Trick to test view controllers in swift” Hah! Thanks for the post.
Walt

Found this recently https://github.com/klaaspieter/KPAViewControllerTestHelper
Ali Turab Gilani

I have always used this trick to properly trigger lifecyle of viewControllers. But I actually never added the controller to UIWindow. #learntSomethingToday #Thanks
Grant Kemp

Thanks for this Natasha, I found it quite strange that just instantiating the View Controller didn’t start the lifecycle. Seems very strange why you would instantiate a Vc without starting the Lifecycle. Is there a reason for this?
Hector Partidas

I was having this particular issue today and solved it by using the suggestion here with let _ = viewController.view.

After discussing it with a co-worker, he pointed out that it could be replaced with:

viewController.layoutSubviews()

Which indeed, has the same functionality and is much cleaner imo.
Ali Turab Gilani

We recently had this issue at Concur while some tests were failing. I’d highly discourage using UIWindow object to trigger viewController’s lifecycle. Simply using _ = viewController.view should trigger viewDidLoad which should be enough for testing.

Using UIWindow object, would also trigger the viewWillAppear and viewWillDisappear part of lifecycle which only gets executed either at the end of current runloop or in the next iteration. It randomly causes other tests who do async testing to fail.

Simply using _ = viewController.view should be enough.

@atastrophic
Daniel Carlos

You can use the function loadViewIfNeeded() instead of using the getter of view
Esben Bücking-Rasmussen

Accessing .view seem to work fine in Obj-C. But while rewriting my app to SWIFT 4, I can’t get the view to render by accessing the .view property.
I have a MKMapView on my viewcontroller and I can’t trigger themapview to start loading by acessing the .view property.
The other suggestions here like using loadViewIfNeeded etc. doesen’t wort either.
Any other suggestions i Could try?