behaviour

SwiftyMocky

Join our community on Slack! -> invitation link here

Check out guides, or full documentation

Overview

SwiftyMocky is Lightweight, strongly typed framework for Mockito-like unit testing experience. As Swift doesn't support reflections well enough to allow building mocks in runtime, library depends on Sourcery, that scans your source code and generates Swift code for you.

The idea of SwiftyMocky is to mock Swift protocols. The main features are:

• easy syntax, utilising full power of auto-complete, which makes writing test easier and faster
• we DO support generics
• mock implementations generation
• a way to specify what mock will return (given)
• possibility to specify different return values for different attributes
• record stubbed return values sequence
• verify, whether a method was called on mock or not
• check method invocations with specified attributes
• it works with real device

Installation

SwiftyMocky is available through CocoaPods. To install it, simply add the following line to your Podfile:

pod "SwiftyMocky"

Then add mocky.yml and Rakefile (or build script phase) to your project root directory, as described in below. See full setup instructions.

For Carthage install instructions, see full documentation.

Generating mocks implementations:

One of the boilerplate part of testing and development is writing and updating mocks accordingly to newest changes. SwiftyMocky is capable of generating mock implementations (with configurable behavior), based on protocol definition.

During development process it is possible to use SwiftyMocky in a watcher mode, which will observe changes in you project files, and regenerate files on the fly.

By default, all protocols marked as AutoMockable (inheriting from dummy protocol AutoMockable or annotated with //sourcery: AutoMockable) are being subject of mock implementation generation. All mocks goes to Mock.generated.swift, which can be imported into test target.

How to start using SwiftyMocky

Mocks generation is based on mocky.yml file.

First, create file in your project root directory with following structure:

sources:
  include:
    - ./ExampleApp
    - ./ExampleAppTests
templates:
  - ./Pods/SwiftyMocky/Sources/Templates
output:
  ./ExampleApp
args:
  testable:
    - ExampleApp
  import:
    - RxSwift
    - RxBlocking
  excludedSwiftLintRules:
    - force_cast
    - function_body_length
    - line_length
    - vertical_whitespace

• sources: all directories you want to scan for protocols/files marked to be auto mocked, or inline mocked. You can use exclude, to prevent from scanning particular files (makes sense for big *.generated.swift files)
• templates: path to SwiftyMocky sourcery templates, in Pods directory
• output: place where Mock.generated.swift will be placed
• testable: specify imports for Mock.generated, that should be marked as @testable (usually tested app module)
• import: all additional imports, external libraries etc. to be placed in Mock.generated
• excludedSwiftLintRules: if using swift SwiftLint.

If you are already using Sourcery with your own templates and you have configured sourcery.yml file, you can extend it to add support for SwiftyMocky. Click here for details.

Generate mocks:

1. manually: by triggering:

Pods/Sourcery/bin/sourcery --config mocky.yml

1. in watch mode: changed methods will be reflected in mocks, after generation of mock, by triggering:

Pods/Sourcery/bin/sourcery --config mocky.yml --watch

!!! In case of incompatibile swift module versions error - check Known issues section in guides or docs

Don't forget to add Mock.generated.swift to your test target :)

Please Note! Most convenient way is to put generation in some kind of script - like Rakefile below. Just create file named Rakefile - generation is triggered by rake mock

# Rakefile
task :mock do
  sh "Pods/Sourcery/bin/sourcery --config mocky.yml"
end

task :mock_watcher do
  sh "Pods/Sourcery/bin/sourcery --config mocky.yml --watch"
end

Marking protocols to be mocked

Mark protocols that are meant to be mocked with sourcery annotation as following:

//sourcery: AutoMockable
protocol ToBeMocked {
  // ...
}

Every protocol in source directories, having this annotation, will be added to Mock.generated.swift

@objc protocols are also supported, but needs to be explicitly marked with ObjcProtocol annotation:

//sourcery: AutoMockable
//sourcery: ObjcProtocol
@objc protocol NonSwiftProtocol {
  // ...
}

Stubbing return values for mock methods - Given

All mocks has given method (accessible both as instance method or global function), with easy to use syntax, allowing to specify what should be return values for given methods (based on specified attributes).

All protocol methods are nicely put into Given, with matching signature. That allows to use auto-complete (just type .) to see all mocked protocol methods, and specify return value for them.

All method attributes are wrapped as Parameter enum, allowing to choose between any and value, giving great flexibility to mock behaviour. Please consider following:

Given(mock, .surname(for name: .value("Johnny"), willReturn: "Bravo"))
Given(mock, .surname(for name: .any, willReturn: "Kowalsky"))

print(mock.surname(for: "Johny"))   // Bravo
print(mock.surname(for: "Mathew"))  // Kowalsky
print(mock.surname(for: "Joanna"))  // Kowalsky

In verions 3.0 we introduced sequences and policies for better control of mock behvaiour.

Given(mock, .surname(for name: .any, willReturn: "Bravo", "Kowalsky", "Nguyen"))

print(mock.surname(for: "Johny"))   // Bravo
print(mock.surname(for: "Johny"))   // Kowalsky
print(mock.surname(for: "Johny"))   // Nguyen
print(mock.surname(for: "Johny"))   // and again Bravo
// ...

For more details please see full documentation.

Check invocations of methods, subscripts and properties - Verify

All mocks has verify method (accessible both as instance method or global function), with easy to use syntax, allowing to verify, whether a method was called on mock, and how many times. It also provides convenient way to specify, whether method attributes matters (and which ones).

All protocol methods are nicely put into Verify, with matching signature. That allows to use auto-complete (just type .) to see all mocked protocol methods, and specify which one we want to verify.

All method attributes are wrapped as Parameter enum, allowing to choose between any, value and matching, giving great flexibility to tests. Please consider following:

// inject mock to sut. Every time sut saves user data, it should trigger storage storeUser method
sut.usersStorage = mockStorage
sut.saveUser(name: "Johny", surname: "Bravo")
sut.saveUser(name: "Johny", surname: "Cage")
sut.saveUser(name: "Jon", surname: "Snow")

// check if Jon Snow was stored at least one time
Verify(mockStorage, .storeUser(name: .value("Jon"), surname: .value("Snow")))
// storeUser method should be triggered 3 times in total, regardless of attributes values
Verify(mockStorage, 3, .storeUser(name: .any, surname: .any))
// storeUser method should be triggered 2 times with name Johny
Verify(mockStorage, 2, .storeUser(name: .value("Johny"), surname: .any))
// storeUser method should be triggered at least 2 times with name longer than 3
Verify(mockStorage, .moreOrEqual(to: 2), .storeUser(name: .matching({ $0.count > 3 }}), surname: .any))

For Verify, you can use Count to specify how many times you expect something to be triggered. Count can be defined as explicit value, like 1,2,... or in more descriptive and flexible way, like .never, more(than: 1), etc.

From SwiftyMocky 3.0, it is possible to use Given and perform Verify on properties as well, with respect to whether it is get or set:

mock.name = "Danny"
mock.name = "Joanna"

print(mock.name)

// Verify getter:
Verify(mock, 1, .name)
// Verify setter:
Verify(mock, 2, .name(set: .any))
Verify(mock, 1, .name(set: .value("Danny")))
Verify(mock, .never, .name(set: .value("Bishop")))

The old VerifyProperty is now deprecated. We also deprecated using setters for readonly properties, in favour of using Given.

All supported features

For list all supported features, check documentation here or guides

Example of usage

For more examples, check out our example project, or examples section in guides.

To run the example project, clone the repo, and run pod install from the Example directory first.

To trigger mocks generation, run rake mock from root directory. For watcher mode, when mocks are generated every time you change your file projects, use rake mock_watcher instead.

Documentation

Full documentation is available here, as well as through docs directory.

Guides - Table of contents

Changelog is available here

Roadmap

• stubbing protocols in elegant way
• template for generating mocks
• example project
• stubbing protocols with variables
• method signature generation without name conflicts
• cover 95% of framework codebase with unit tests
• cover 95% of framework codebase with documentation
• add unit tests for template
• support for tvOS, Linux and MacOS
• Carthage support
• Subscripts support
• Stub return values as sequences
• Simple tool simplifying configuration process

Current version

As we value stability, there should be no breaking changes in version 3.1.0. Nevertheless, we explicitly marked some parts as deprecated, as they will be removed in version 3.2.x. The main reason is because we want to simplify and unify mocking experience.

Authors

• Przemysław Wośko, wosko.przemyslaw@gmail.com
• Andrzej Michnia, amichnia@gmail.com

License

SwiftyMocky is available under the MIT license. See the LICENSE file for more info.