I ran into an interesting problem when trying to test that a delegate was set. Here’s a simplified example:

protocol MyProtocol {
  func myMethod()
}

class ClassWithDelegate {
  var delegate: MyProtocol?
  ...
}

class ClassUnderTest: MyProtocol {
  var otherClass: ClassWithDelegate

  init() {
    self.otherClass = ClassWithDelegate()
    self.otherClass.delegate = self
  }
}

In order to test that our ClassUnderTest is instantiating the ClassWithDelegate and setting its delegate, we could do the following:

class OurTests: XCTestCase {
  var testClass: ClassUnderTest()

  ...

  func testThatOtherClassCreated {
    XCTAssertNotNil(testClass.otherClass)
  }

  func testThatOtherClassDelegateSet {
    XCTAssertTrue(testClass.otherClass.delegate === testClass)
  }
}

This looks pretty simple, right? For those of us still learning Swift, it isn’t simple. What happens is that the compiler refuses to build, with the error: ‘MyProtocol’ is not identical to ‘AnyObject’.

After tons of reading, and learning a lot about Swift protocols and pointers, I basically stumbled upon the solution: add the “class” keyword to the protocol. This tells the compiler that only objects will implement the protocol, not structs. It then is quite happy to perform tests for nil and/or identicalness (?). So the working protocol definition looks like this:

protocol MyProtocol : class {
  func myMethod()
}

Now all the other code works.

I’ve been working with a Swift project, and recently decided to add MMWormhole to it. This is the first Objective-C code to be added to this project, so I needed to review the Apple WWDC 2014 videos and developer documentation to figure out how to that.

It appears at first glance that the process is very simple. At least, it should be. What I ran into though appears to be bugs in Xcode.

The first bug I ran into was a problem with the prompt to automatically create the bridging header. When an Objective-C file is added to an all-Swift project, Xcode is supposed to ask you if you’d like a bridging header to be created, and then do so. This didn’t happen, but it’s no big deal. The bridging header can be easily created manually. This is pretty simple, but may not work depending on whether you hit the second bug I ran into, described further on.

1. Create a new header file. Name it -Bridging-Header.h (substituting with the name of your project)
2. Search for the “Objective-C Bridging Header” setting, and set its value to point to the file just created
3. Repeat step 2 for the test target if you’re going to do any testing that needs to reference the Objective-C code also. This shouldn’t be necessary in most cases, but I needed to do so in order to write a unit test to try to catch the second bug.

The second bug is much worse. It appears that once a project starts getting bigger or more complex, the bridging header just stops working. By that I mean that the objects included using the bridging header (MMWormhole in my case) stop being found, even if previously building ok.

I’m in the process of recreating my project to try to determine exactly what steps cause the bridging header to stop working. I’ll update this post once I’ve found it.

Update 3/11/15

A friend of mine ran into an issue when trying to test a Swift class that had been added to his otherwise Objective-C project. Since he already had a good suite of Objective-C tests, he simply wanted to add an Objective-C test. This caused various compile errors. The solution was to add the Swift file to the test target.

By default, tests are run as “application tests”. This means that the tests are injected into the application. Hence tests have access to everything in the application. However, Swift files are compiled into a separate module during the build process, and thus not visible to the test target. You can think of this as meaning that Swift files are in effect run as “library tests”, and thus must be added to the test target to be visible.

I’ve become a fan of creating one’s own test doubles (aka mock objects) instead of using a mock framework like OCMock or OCMockito. Uncle Bob describes this process in one of his Clean Code videos, and it seems to work very well in Swift.

Why create your own mock objects? There are a couple reasons for doing this.

1. Tests can be more readable.
   I say “can” because its really up to you to create readable mocks.
2. You have nearly unlimited faking capability.
   I say “nearly” because there are some things that may not be possible using class inheritance, for example overriding methods or properties that have been marked as “final“.

So let’s take a look at using manually created fake doubles for testing a simple Power class. This class has one purpose: to report whether or not the device is plugged-in. The way this is done on an iOS device is by using the batteryState property of the UIDevice currentDevice singleton.

Uh-oh, did I just say “singleton”? Yep. That’s typically bad news for unit testing. However, this won’t be a problem for us because we’re going to replace the UIDevice singleton with our own fake object. This means that we’ll have to follow the “tell, don’t ask” principle, and pass in the UIDevice object to our Power object instead of letting it “ask” for the singleton UIDevice currentDevice object.

class Power {

   var device: UIDevice

   init() {
      self.device = UIDevice.currentDevice()
   }

   init(usingMockDevice mockDevice: UIDevice) {
      device = mockDevice
   }

   func isPluggedIn() -> Bool {
      let batteryState = self.device.batteryState
      let isPluggedIn = batteryState ==    UIDeviceBatteryState.Charging || batteryState ==  UIDeviceBatteryState.Full
      return isPluggedIn
   }

}

Here we’re using separate initializer methods to allow passing in a fake UIDevice object, or default to using the singleton currentDevice. Normal production code usage would look something like this:

   var power = Power()
   ...
   if power.isPluggedIn() {
   ...

On the other hand, for testing this we’ll create a test double and use it with the usingMockDevice initializer as shown here:

class mockPluggedInDevice: UIDevice {
   override var batteryState: UIDeviceBatteryState {
      return UIDeviceBatteryState.Full
   }
}

class PowerTests: XCTestCase {

   func testPluggedInWhenBatteryFull() {
      let mockDevice = mockPluggedInDevice()
      let power = Power(usingMockDevice: mockDevice)
      XCTAssertTrue(power.pluggedIn())
   }
}

So here’s a question for you. In which file do we put the mockPluggedInDevice code? I’m a bit conflicted on this. On one hand, I usually prefer to keep test code completely out of product code files. But on the other hand, mock objects are by nature going to be pretty dependent on the product code they are mocking, so I should probably keep it with the product code.

Clarification: For simplicity, I am using the term “mock” object to describe what would more accurately be called a “stub”. Martin Fowler clearly defines the difference in this 2007 article.