Unit Testing - Mocking In Swift

Mocking is a useful tool when writing unit tests. Due to limitations in the current swift version, there aren’t any real mocking frameworks like the ones you see for Java and Obj-C. That said, there are work arounds. Here’s a quick one when you need a one-off:

Method to test:

func crossDissolve(toIdentifier identifier: StoryboardIdentifier) {
    let nextViewController = viewController(forIdentifier: identifier)
    nextViewController.modalPresentationStyle = .fullScreen
    nextViewController.modalTransitionStyle = .crossDissolve
    show(nextViewController, sender: self)

This just performs a simple cross-dissolve between two view controllers (the one it’s on to the new one).There are four things to validate:

  1. The UIViewController passed to show(_:sender:) is the one expect.
  2. The sender is correct
  3. That the presentation style is fullScreen
  4. The transition style is crossDissolve

Since it doesn’t return any values I’m going to have to capture them instead. The method under test is crossDissolve(…) so I don’t want to change that behaviour. Everything else is fair game though. In this case, if I intercept the call to show(…) I can capture the parameters passed and validate them.

Since this is a one-off I can nest a class inside my test and capture the values appropriately. Then I can fill in the test.

func testCrossDissolve() {
    class MockSut: UIViewController {
        var showViewController: UIViewController?
        var showSender: Any?
        override func show(_ vc: UIViewController, sender: Any?) {
            showViewController = vc
            showSender = sender
    let mockSut = MockSut()
    mockSut.crossDissolve(toIdentifier: .gameViewController)
    XCTAssertNotNil(mockSut.showViewController as? GameViewController)
    XCTAssertEqual(mockSut.showSender as? UIViewController, mockSut)
    XCTAssertEqual(mockSut.showViewController?.modalPresentationStyle, .fullScreen)
    XCTAssertEqual(mockSut.showViewController?.modalTransitionStyle, .crossDissolve)

So, we’re creating a subclass of UIViewController and overriding a method that is called by the method we are interested in testing. Then we can use assertions to complete our test.

Of course, this could get messy if we had a bunch of test cases which needed to handle overrides. In that case I’d move the MockSut class out of the function and into the parent class. If I needed it outside of this specific set of tests, I’d move it into its own class so it could be used in multiple places.

Cleaning Up The Code

So, looking back over the last code, I realised that I was overthinking it massively. The original reasoning behind it didn’t hold up, so I fixed it.

protocol NavigationProtocol {
    func viewController(forIdentifier identifier: StoryboardIdentifier) -> UIViewController

extension NavigationProtocol {
    private var storyboard: UIStoryboard {
        return UIStoryboard(name: "Main", bundle: nil)

    func viewController(forIdentifier identifier: StoryboardIdentifier) -> UIViewController {
        return storyboard.instantiate(withIdentifier: identifier)

Yep, that’s a bit smaller. Hooray.

Bonus - time for unit tests ;)

func testInstantiateViewController_Splash() {
        let viewController = sut.viewController(forIdentifier: .splashViewController)
        XCTAssertTrue(viewController is SplashViewController)

    func testInstantiateViewController_MainMenu() {
        let viewController = sut.viewController(forIdentifier: .mainMenuViewController)
        XCTAssertTrue(viewController is MainMenuViewController)

Swift: Initialising a 2D Array

I have a struct called Tile, which has (for now) a position defined as a tuple:

struct Tile {
    let pos: (Int, Int)

And a class called Board, which has a 2D array of Tile objects:

class Board {
    let tiles: [[Tile]]
    init() {
        var tilesArray = [[Tile]]()
        for row in 0..<Board.rows {
            var rowTiles = [Tile]()
            for column in 0..<Board.columns {
                let tile = Tile(pos:(column, row))
        tiles = tilesArray      

This works, though it feels a little messy... I'll have to come back and look at this again.

Xcode 7 and Swift 2: Unit Testing (again)

Some follow up from creating a new project and adding tests.

This turned out to be important...

This turned out to be important...

I hadn't really noticed in the last one but I hadn't added the new classes to the test target, as I would under Obj-C. In Swift 2 there's a new @testable keyword. I found it blogged by Natasha the Robot when I started looking to find out why I wasn't seeing any code coverage showing up for my classes.

Then I started wondering why I was getting Undefined Symbol errors. I could resolve them by including the classes, but then I wouldn't get coverage and everything I saw on @testable assured me I didn't need to include them. Finally, I remembered I'd been getting a bit click happy earlier. I'd disabled Allow testing Host Application APIs.

One checkbox later and I'm a happy camper...

Okay, not a lot done tonight but I feel like a few pieces fell into place.