SwiftyMocky

Join our community on Slack! -> invitation link here

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 SwiftyMokcy is to mock Swift protocols. The main features are:

easy syntax, utilizing full power of auto-complete, which makes writing test easier and faster
mock implementations generation
a way to specify what mock will return (given)
possibility to specify different return values for different attributes
verify, whether a method was called on mock or not
check method invocations with specified attributes

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.

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(String.self), willReturn: "Kowalsky"))

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

Check invocations of methods - 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.

Check property getters and setters - VerifyProperty

From SwiftyMocky 2.0, it is possible to perform VerifyProperty. Syntax is very similar to plain Verify, with respect to whether it is get or set:

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

print(mock.name)

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

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

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.

Generate mocks:

manually: by triggering:

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

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 {
  // ...
}

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
add unit tests for template
support for tvOS, Linux and MacOS
Carthage support

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 above.

For Carthage install instructions, see full documentation.

Current version

Master branch is stabilizing, breaking changes possible in version 2.0. For more information about upcoming changes - see issues and projects section.

Authors

Przemysław Woś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.

IgorBulyga/SwiftyMocky