SwiftyMock
This repository contains helpers that make mocking, stubbing and spying in Swift much easier
Example
Protocol
Imagine you have some protocol that describes some behaviour
protocol RoboKitten {
func batteryStatus() -> Int
func jump(x x: Int, y: Int) -> Int
func canJumpAt(x x: Int, y: Int) -> Bool
func rest(completed: Bool -> () )
}
Protocol usage
And this protocol is used somewhere
class RoboKittenController {
let kitten: RoboKitten
init(kitten: RoboKitten) {
self.kitten = kitten
}
func jumpAt(x x: Int, y: Int) -> Result {
if kitten.canJumpAt(x: x, y: y) {
kitten.jump(x: x, y: y)
return .SUCCESS
}
return .FAILURE
}
...
}
Protocol mock
So now you want to test how protocol is used as a dependency
And you create to create mock implementation of protocol
And create fake calls for each method you want to test
So here how it will look like in SwiftyMock
class RoboKittenMock: RoboKitten {
let batteryStatusCall = FunctionCall<(), Int>()
func batteryStatus() -> Int {
return stubCall(batteryStatusCall, argument:())
}
let jumpCall = FunctionCall<(x: Int, y: Int), Int>()
func jump(x x: Int, y: Int) -> Int {
return stubCall(jumpCall, argument: (x: x, y: y))
}
let canJumpAtCall = FunctionCall<(x: Int, y: Int), Bool>()
func canJumpAt(x x: Int, y: Int) -> Bool {
return stubCall(canJumpAtCall, argument: (x: x, y: y))
}
let restCall = FunctionCall<Bool -> (), ()>()
func rest(completed: Bool -> ()) {
return stubCall(restCall, argument: completed, defaultValue: ())
}
}
Mock usage
If setup was correct it's really easy to specify mock behaviour by using subbed methods
Method stub
Let's say we want to our mock to return some values
It's really easy
// like this
kittenMock.canJumpAtCall.returns(false)
// or like this
kittenMock.jumpCall.returns(20)
Sometimes, you have bit more complex rules when and what to return
// You can add as many filters you like
// More specific rules overrides general rules
kittenMock.canJumpAtCall
.on { $0.x < 0 }.returns(false)
.on { $0.y < 0 }.returns(false)
.returns(true) // in all other cases
And sometimes you need even more complex mock behaviour, when you need for example to pass closures into mock
protocol RoboKitten {
func rest(completed: Bool -> () )
}
kittenMock.restCall.performs { completion in
print("Mock method was called! Remove this in prod version:))")
completion(true)
}
Method call check
Also from time to time, you need to be sure that method was called
beforeEach {
// Since canjump method need to return somtehing we need to specify return value
kittenMock.canJumpAtCall.returns(false)
}
it("should ask kitten if it's available to jump there") {
sut.jumpAt(x: 10, y: 20)
expect(kittenMock.canJumpAtCall.called).to(beTruthy())
}
Or you need to check that method was called exact number of times
it("should actually ask kitten to jump only once per call") {
sut.jumpAt(x: 18, y: 23)
expect(kittenMock.jumpCall.callsCount).to(equal(1))
sut.jumpAt(x: 80, y: 15)
expect(kittenMock.jumpCall.callsCount).to(equal(2))
}
All method calls are stored in the mock, so you can easily check if mock was called with correct parameters
it("should ask kitten if it's available to jump there with the same coords") {
sut.jumpAt(x: 10, y: 20)
expect(kittenMock.canJumpAtCall.capturedArgument?.x).to(equal(10))
expect(kittenMock.canJumpAtCall.capturedArgument?.y).to(equal(20))
}
ReactiveSwift stubs support
API for methods that return SignalProducer
or Action
is pretty much the same as for usual methods stubs.
Imagine RoboKitten protocol is a bit changed and returns SignalProducer instead of plain value, so we can keep and eye on battery status level.
protocol RoboKitten {
func batteryStatus() -> SignalProducer<Int, NoError>
}
Now you create mock implementation of this protocol, but instead of FunctionCall
, you're using ReactiveCall
.
The only difference is that we've added third type constraint to specify Error
.
class RoboKittenMock: RoboKitten {
let batteryStatusCall = ReactiveCall<(), Int, NoError>()
func batteryStatus() -> SignalProducer<Int, NoError> {
return stubCall(batteryStatusCall, argument:())
}
}
Method stub
Since SignalProducer
is constrained by Value and Error types, we need to allow user to choose, which one to stub call with.
Luckily there's handy Result type and its implementation comes along with ReactiveSwift.
Thus in order to stub ReactiveCall
, you use Result
instead of plain value as you did with FunctionCall
.
// like this
kittenMock.batteryStatusCall.returns(.success(42))
// or
kittenMock.batteryStatusCall.returns(Result(value: 42))
// or in case you want this stub to return failure
kittenMock.batteryStatusCall.returns(.failure(ImagineThisIsError))
// or
kittenMock.batteryStatusCall.returns(Result(error: ImagineThisIsError))
Everything else stays the same :)
Matchers
SwiftyMock doesn't have its own matchers, so you can use whatever matchers suits better for you :)
Templates
You can generate mocks automatically with Sourcery.
First, create sourcery config yml and specify paths to sources, templates, generated output and testable import framework for tests.
You can take a look at how .sourcery.yml
here in the root looks like.
sources:
- ./Example/SwiftyMock/RoboKitten
templates:
- ./SwiftyMock/Templates
output:
path: ./Example/RoboKittenTests/Mocks/Generated
args:
testable: SwiftyMock_Example # here you specify your application module name, that you're importing for testing
Second, annotate protocols that you want to generate mocks for, with // sourcery: Mock
comment:
// sourcery: Mock
protocol RoboKitten {
// ...
}
Third, run sourcery command sourcery --config .sourcery.yml --watch
if you want to run service that will regenerate mocks every time your source files or templates change.
Or sourcery --config .sourcery.yml
if you want to generate mocks once.