// Mocking
let bird = mock(Bird.self)

// Stubbing
given(bird.getName()) ~> "Ryan"

// Verification
verify(bird.fly()).wasCalled()

Mockingbird is a Swift mocking framework that lets you throw away your hand-written mocks and write clean, readable tests.

• Expansive coverage of Swift language features
  • Mock classes and protocols in a single line of code
  • Support for generics, inheritance, static members, nested classes, type aliasing, etc.
• Seamless integration with Xcode projects
  • Automatic discovery of source and dependency files
  • Handling of external types from third-party libraries
• Convenient testing API
  • Clear stubbing and verification error messages
  • Support for asynchronous code, in order verification, default return value stubbing, etc.

Mockingbird consists of two main components: the generator and the testing framework. Before each test bundle compilation, configurable mock objects are created by implementing protocols and subclassing classes. The testing framework hooks into the generated code and provides APIs for mocking, stubbing, and verification.

protocol Bird {
  var canFly: Bool { get }
  func fly()
}

class Tree {
  let bird: Bird
  
  init(with bird: Bird) {
    self.bird = bird
  }
  
  func shake() {
    guard bird.canFly else { return }
    bird.fly()
  }
}

func testShakingTreeCausesBirdToFly() {
  // Given a tree with a bird that can fly
  let bird = mock(Bird.self)
  let tree = Tree(with: bird)
  given(bird.getCanFly()) ~> true
  
  // When the tree is shaken
  tree.shake()
  
  // Then the bird flies away
  verify(bird.fly()).wasCalled()
}

Add the framework to a test target in your Podfile, making sure to include the use_frameworks! option.

target 'MyTestTarget' do
  use_frameworks!
  pod 'MockingbirdFramework', '~> 0.11'
end

Initialize the pod.

$ pod install

Then install the CLI.

$ cd Pods/MockingbirdFramework
$ make install-prebuilt

Add the framework to your Cartfile.

github "birdrides/mockingbird" ~> 0.11

Build the framework using Carthage and link it to your test target, making sure to add the framework to a Copy Files build phase with the destination set to Frameworks.

$ carthage update

Then install the CLI.

$ cd Carthage/Checkouts/mockingbird
$ make install-prebuilt

Add https://github.com/birdrides/mockingbird as a dependency and link it to your test target.

Then download and install the latest CLI from Releases.

Clone the repository and build the MockingbirdFramework scheme for the desired platform. Drag the built Mockingbird.framework product into your project and link it to your test target.

$ git clone https://github.com/birdrides/mockingbird.git
$ cd mockingbird
$ open Mockingbird.xcodeproj

Then build and install the CLI.

$ make install

Use the CLI to configure a test target, listing all source targets that should generate mocks before each build. Below, mock types will be generated for the Bird app target and the BirdManagers framework target, which can then be used in BirdTests.

$ mockingbird install \
  --target BirdTests \
  --sources Bird BirdManagers

Need to set up your project manually?

For basic compatibility with the Swift standard library and other system frameworks, download the latest starter supporting source files and place the MockingbirdSupport folder in the root directory of your project. Note that supporting source files should not be imported into Xcode or added to any targets. See Supporting Source Files for more information.

You can exclude unwanted or problematic sources from being mocked by adding a .mockingbird-ignore file. Mockingbird follows the same pattern format as .gitignore and scopes ignore files to their enclosing directory.

Example projects demonstrating basic usage of Mockingbird:

• CocoaPods tutorial + example project
• Carthage tutorial + example project

Mock types can be passed in place of the original type and are suffixed with Mock. Avoid explicitly coercing mock types into their supertype, as this breaks stubbing and verification.

Note that the initialized mock type is BirdMock instead of Bird.

let bird: BirdMock = mock(Bird.self)  // The concrete type is `BirdMock`
let inferredBird = mock(Bird.self)    // but type inference also works

Initialize concrete class mocks using the initialize method. Keep in mind that class mocks rely on subclassing which has certain limitations, so consider using protocol mocks whenever possible.

class Bird {
  let name: String
  init(named name: String) { self.name = name }
}
let bird = mock(Bird.self).initialize(named: "Ryan")

Stubbing allows you to define a custom value to return when a mocked method is called.

given(bird.getName()) ~> "Ryan"

You can use an argument matcher when stubbing methods with parameters. Stubs added later have precedence over those added earlier, so stubs containing specific matchers should be added last.

given(bird.canChirp(volume: any())) ~> false    // Matches any volume
given(bird.canChirp(volume: notNil())) ~> true  // Matches any non-nil volume
given(bird.canChirp(volume: 10)) ~> false       // Matches volume = 10

Stub variables with their getter and setter methods.

given(bird.getName()) ~> "Ryan"
given(bird.setName(any())) ~> { print($0) }

Getters can be stubbed to automatically save and return values.

given(bird.getName()) ~> lastSetValue(initial: "Ryan")
bird.name = "Sterling"
print(bird.name)  // Prints "Sterling""

Use a closure to implement complex stubs that contain logic or that interact with arguments.

given(bird.chirp(volume: any(), callback: any())) ~> { volume, callback in
  callback(volume * 2)
}

Closures also allow for stubbing methods that can throw errors.

given(bird.chirp(volume: any())) ~> { volume in
  if volume > 42 {
    throw BirdError.invalidVolume
  }
}

Mocks are strict by default, meaning that calls to unstubbed methods will trigger a test failure. Methods returning Void do not need to be stubbed in strict mode.

let bird = mock(Bird.self)
print(bird.name)  // Fails because `bird.getName()` is not stubbed
bird.fly()        // Okay because `fly()` has a `Void` return type

To return default values for unstubbed methods, use a ValueProvider with the initialized mock. Default values have a lower precedence than values returned from concrete stubs.

let valueProvider = ValueProvider().register("Ryan", for: String.self)
let bird = mock(Bird.self)
useDefaultValues(from: valueProvider, on: bird)
print(bird.name)  // Prints "Ryan"

// Values from concrete stubs have a higher precedence 
given(bird.getName()) ~> "Sterling"
print(bird.name)  // Prints "Sterling"

Mockingbird provides several preset value providers which are guaranteed to be backwards compatible.

.standardProvider
├── .collectionsProvider
├── .primitivesProvider
├── .basicsProvider
├── .geometryProvider
├── .stringsProvider
└── .datesProvider

let bird = mock(Bird.self)
useDefaultValues(from: .standardProvider, on: bird)
print(bird.name)  // Prints ""

Verification lets you assert that a mock received a particular invocation during its lifetime.

verify(bird.fly()).wasCalled()

Verifying doesn’t remove recorded invocations, so it’s safe to call verify multiple times (even if not recommended).

verify(bird.fly()).wasCalled()  // If this succeeds...
verify(bird.fly()).wasCalled()  // ...this also succeeds

Argument matching for verification follows the same syntax as stubbing.

verify(bird.canChirp(volume: any())).wasCalled()     // Called with any volume
verify(bird.canChirp(volume: notNil())).wasCalled()  // Called with any non-nil volume
verify(bird.canChirp(volume: 10)).wasCalled()        // Called with volume = 10

Verify variable invocations using their getter and setter methods.

verify(bird.getName()).wasCalled()
verify(bird.setName(any())).wasCalled()

It’s possible to verify that an invocation was called a specific number of times with a count matcher.

verify(bird.fly()).wasNeverCalled()            // n = 0
verify(bird.fly()).wasCalled(exactly(10))      // n = 10
verify(bird.fly()).wasCalled(atLeast(10))      // n ≥ 10
verify(bird.fly()).wasCalled(atMost(10))       // n ≤ 10
verify(bird.fly()).wasCalled(between(5...10))  // 5 ≤ n ≤ 10

Count matchers also support chaining and negation using logical operators.

verify(bird.fly()).wasCalled(not(exactly(10)))           // n ≠ 10
verify(bird.fly()).wasCalled(exactly(10).or(atMost(5)))  // n = 10 || n ≤ 5

Sometimes you need to perform custom checks on argument values by using an argument captor.

let nameCaptor = ArgumentCaptor<String>()
verify(bird.setName(nameCaptor.matcher)).wasCalled()
assert(nameCaptor.value?.hasPrefix("R"))

To enforce the relative order of invocations, use an inOrder block.

// Verify that `fly` was called before `chirp`
inOrder {
  verify(bird.fly()).wasCalled()
  verify(bird.chirp()).wasCalled()
}

Pass options to ordered verification blocks for stricter checks with additional invariants.

inOrder(with: .noInvocationsAfter) {
  verify(bird.fly()).wasCalled()
  verify(bird.chirp()).wasCalled()
}

You can test asynchronous code by using an eventually block which returns an XCTestExpectation.

DispatchQueue.main.async {
  Tree(with: bird).shake()
}
let expectation = eventually {
  verify(bird.fly()).wasCalled()
  verify(bird.chirp()).wasCalled()
}
wait(for: [expectation], timeout: 1.0)

For methods overloaded by return type, you should help the compiler by specifying the type returned.

protocol Bird {
  func getMessage<T>() -> T
  func getMessage() -> String
  func getMessage() -> StaticString
}

verify(bird.getMessage()).returning(String.self).wasCalled()

Occasionally it’s necessary to remove stubs or clear recorded invocations.

reset(bird)                    // Removes all stubs, values, and invocations
clearStubs(on: bird)           // Only removes stubs
clearDefaultValues(on: bird)   // Only removes default values
clearInvocations(on: bird)     // Only removes recorded invocations

Argument matching allows you to handle parameterized methods for stubbing or verification.

Match specific values by passing a concrete instance. The parameter type must explicitly conform to Equatable or the arguments will be compared by reference.

// Many Swift standard library types such as `String` conform to `Equatable`
verify(bird.setName("Ryan")).wasCalled()

// Types that explicitly conform to `Equatable` work out of the box
struct Fruit: Equatable {
  let size: Int
}
verify(bird.eat(Fruit(size: 42))).wasCalled()

// Classes can be safely compared by reference
class Tree {
  init(with bird: Bird) {
    bird.home = self
  }
}
let tree = Tree(with: bird)
verify(bird.setHome(tree)).wasCalled()

Argument matchers allow wildcard and custom matching of arguments that don’t conform to Equatable.

any()                    // Matches any value
any(of: 1, 2, 3)         // Matches any value in {1, 2, 3}
any(where: { $0 > 42 })  // Matches any number greater than 42
notNil()                 // Matches any non-nil value

For methods overloaded by parameter type (such as with generics), using a matcher may cause ambiguity for the compiler. You can help the compiler by specifying an explicit type in the matcher.

any(Int.self)
any(Int.self, of: 1, 2, 3)
any(Int.self, where: { $0 > 42 })
notNil(String?.self)

You can also match elements or keys within collection types.

any(containing: 1, 2, 3)  // Matches any collection with values {1, 2, 3}
any(keys: "a", "b", "c")  // Matches any dictionary with keys {"a", "b", "c"}
any(count: atMost(42))    // Matches any collection with at most 42 elements
notEmpty()                // Matches any non-empty collection

Mathematical operations on floating point numbers can cause unexpected behavior, so consider using around to fuzzily match floating point arguments with some tolerance.

around(10.0, tolerance: 0.01)

Add supporting source files whenever inheriting or conforming to types defined outside of your project. For example protocol BirdBrain: Codable {} inherits from the Swift standard library type Codable. In order to generate the methods encode(to:) and init(from:) for BirdBrain, the definition for Codable needs to exist in the supporting source files like so:

/* MockingbirdSupport/Swift/Codable.swift */

public protocol Encodable {
  func encode(to encoder: Encoder) throws
}

public protocol Decodable {
  init(from decoder: Decoder) throws
}

public typealias Codable = Decodable & Encodable

Supporting source files do not allow you to generate mocks for external types such as those defined in third-party libraries or frameworks. Please see Mocking External Types for details and best practices.

Mockingbird includes starter supporting source files for the Swift standard library and common system frameworks such as Foundation. Download the latest starter supporting source files and place the MockingbirdSupport folder in the root directory of your project. Note that supporting source files should not be imported into Xcode or added to any targets.

If you share supporting source files between projects, you can specify a custom --support directory when running the CLI installer or generator.

Supporting source files should be contained in a directory that matches the module name. You can define submodules and transitive dependencies by nesting directories.

MockingbirdSupport/
├── Foundation/
│   └── ObjectiveC/
│       └── NSObject.swift
└── Swift/
    ├── Codable.swift
    ├── Comparable.swift
    ├── Equatable.swift
    └── Hashable.swift

With the above file structure, NSObject can be imported from both the Foundation and ObjectiveC modules.

Generate mocks for a set of targets in a project.

mockingbird generate

Set up a destination test target.

mockingbird install

Remove Mockingbird from a (unit test) target.

mockingbird uninstall

Mockingbird will first check if the environment variable $PROJECT_FILE_PATH was set (usually by an Xcode build context). It will then perform a shallow search of the current working directory for an .xcodeproj file. If multiple .xcodeproj files exist then you must explicitly provide a project file path.

By default Mockingbird will generate mocks into the $(SRCROOT)/MockingbirdMocks directory with the file name $(PRODUCT_MODULE_NAME)Mocks.generated.swift.

Mockingbird will recursively look for supporting source files in the $(SRCROOT)/MockingbirdSupport directory.

• Troubleshooting
• Slack channel
• Mockingbird wiki
• CocoaPods tutorial + example project
• Carthage tutorial + example project