Swiftpack.co - Package - Brightify/Cuckoo

Cuckoo

Mock your Swift objects!

CI Status Version SwiftPM compatible Carthage compatible License Platform Slack Status

Introduction

Cuckoo was created due to lack of a proper Swift mocking framework. We built the DSL to be very similar to Mockito, so anyone coming from Java/Android can immediately pick it up and use it.

To have a chat, join our Slack workspace!

How does it work

Cuckoo has two parts. One is the runtime and the other one is an OS X command-line tool simply called CuckooGenerator.

Unfortunately Swift does not have a proper reflection, so we decided to use a compile-time generator to go through files you specify and generate supporting structs/classes that will be used by the runtime in your test target.

The generated files contain enough information to give you the right amount of power. They work based on inheritance and protocol adoption. This means that only overridable things can be mocked. Due to the complexity of Swift it is not easy to check for all edge cases so if you find some unexpected behavior, please file an issue.

Changelog

List of all changes and new features can be found here.

Features

Cuckoo is a powerful mocking framework that supports:

  • ☑ inheritance (grandparent methods)
  • ☑ generics
  • ☑ simple type inference for instance variables (works with initializers, as TYPE notation, and can be overridden by specifying type explicitly)
  • Objective-C mocks utilizing OCMock

What will not be supported

Due to the limitations mentioned above, unoverridable code structures are not supportable by Cuckoo. This includes:

  • struct - workaround is to use a common protocol
  • everything with final or private modifier
  • global constants and functions
  • static properties and methods

Requirements

Cuckoo works on the following platforms:

  • iOS 8+
  • Mac OSX 10.9+
  • tvOS 9+

watchOS support is not yet possible due to missing XCTest library.

Note: Version 1.2.0 is the last one supporting Swift 4.2. Use versions 1.3.0+ for Swift 5 and up.

Cuckoo

1. Installation

CocoaPods

Cuckoo runtime is available through CocoaPods. To install it, simply add the following line to your test target in your Podfile:

pod "Cuckoo"

And add the following Run script build phase to your test target's Build Phases above the Compile Sources phase:

# Define output file. Change "${PROJECT_DIR}/${PROJECT_NAME}Tests" to your test's root source folder, if it's not the default name.
OUTPUT_FILE="${PROJECT_DIR}/${PROJECT_NAME}Tests/GeneratedMocks.swift"
echo "Generated Mocks File = ${OUTPUT_FILE}"

# Define input directory. Change "${PROJECT_DIR}/${PROJECT_NAME}" to your project's root source folder, if it's not the default name.
INPUT_DIR="${PROJECT_DIR}/${PROJECT_NAME}"
echo "Mocks Input Directory = ${INPUT_DIR}"

# Generate mock files, include as many input files as you'd like to create mocks for.
"${PODS_ROOT}/Cuckoo/run" generate --testable "${PROJECT_NAME}" \
--output "${OUTPUT_FILE}" \
"${INPUT_DIR}/FileName1.swift" \
"${INPUT_DIR}/FileName2.swift" \
"${INPUT_DIR}/FileName3.swift"
# ... and so forth, the last line should never end with a backslash

# After running once, locate `GeneratedMocks.swift` and drag it into your Xcode test target group.

IMPORTANT: To make your mocking journey easier, make absolutely sure that the run script is above the Compile Sources phase.

Input files can be also specified directly in Run script in Input Files form.

Note: All paths in the Run script must be absolute. Variable PROJECT_DIR automatically points to your project directory. Remember to include paths to inherited Classes and Protocols for mocking/stubbing parent and grandparents.

Swift Package Manager

To use Cuckoo with Apple's Swift package manager, add the following as a dependency to your Package.swift:

.package(url: "https://github.com/Brightify/Cuckoo.git", .upToNextMajor(from: "1.3.0"))

after that add "Cuckoo" as a dependency of the test target.

If you're unsure, take a look at this example PackageDescription:

// swift-tools-version:4.0
import PackageDescription

let package = Package(
    name: "Friendlyst",
    products: [
        .library(
            name: "Friendlyst",
            targets: ["Friendlyst"]),
    ],
    dependencies: [
        .package(url: "https://github.com/Brightify/Cuckoo.git", .upToNextMajor(from: "1.3.0"))
    ],
    targets: [
        .target(
            name: "Friendlyst",
            dependencies: [],
            path: "Source"),
        .testTarget(
            name: "FriendlystTests",
            dependencies: ["Cuckoo"],
            path: "Tests"),
    ]
)

Cuckoo relies on a script that is currently not downloadable using SwiftPM. However, for convenience, you can copy this line into the terminal to download the latest run script. Unfortunately if there are changes in the run script, you'll need to execute this line again.

curl -Lo run https://raw.githubusercontent.com/Brightify/Cuckoo/master/run && chmod +x run

When you're all set, use the same Run script phase as above and replace

"${PODS_ROOT}/Cuckoo/run"

with

"${PROJECT_DIR}/run" --download

The --download option is necessary because the Generator sources are not cloned in your project (they're in DerivedData, out of reach). You can add a version (e.g. 1.3.0) after it to get a specific version of the cuckoo_generator. Use --clean as well to replace the current cuckoo_generator if you're changing versions.

Carthage

To use Cuckoo with Carthage add this line to your Cartfile:

github "Brightify/Cuckoo"

Then use the Run script from above and replace

"${PODS_ROOT}/Cuckoo/run"

with

"Carthage/Checkouts/Cuckoo/run"

Don't forget to add the Framework into your project.

2. Usage

Usage of Cuckoo is similar to Mockito and Hamcrest. However, there are some differences and limitations caused by generating the mocks and Swift language itself. List of all the supported features can be found below. You can find complete examples in tests.

Mock initialization

Mocks can be created with the same constructors as the mocked type. Name of mock class always corresponds to name of the mocked class/protocol with Mock prefix (e.g. mock of protocol Greeter is called MockGreeter).

let mock = MockGreeter()

Spy

Spies are a special case of Mocks where each call is forwarded to the victim by default. Since Cuckoo version 0.11.0 we changed the way spies work. When you need a spy, give Cuckoo a class to mock instead of a protocol. You'll then be able to call enableSuperclassSpy() (or withEnabledSuperclassSpy()) on a mock instance and it will behave like a spy for the parent class.

let spy = MockGreeter().withEnabledSuperclassSpy()

Note: The behavior was changed due to a limitation of Swift. Since we can't create a real proxy for the spy, calls inside the spy were not caught by the Mock and it was confusing. If you rely on the old behavior (i.e. you use spies with final classes), let us know on Slack or create an issue.

Stubbing

Stubbing can be done by calling methods as a parameter of the when function. The stub call must be done on special stubbing object. You can get a reference to it with the stub function. This function takes an instance of the mock that you want to stub and a closure in which you can do the stubbing. The parameter of this closure is the stubbing object.

Note: It is currently possible for the subbing object to escape from the closure. You can still use it to stub calls but it is not recommended in practice as the behavior of this may change in the future.

After calling the when function you can specify what to do next with following methods:

/// Invokes `implementation` when invoked.
then(_ implementation: IN throws -> OUT)

/// Returns `output` when invoked.
thenReturn(_ output: OUT, _ outputs: OUT...)

/// Throws `error` when invoked.
thenThrow(_ error: ErrorType, _ errors: Error...)

/// Invokes real implementation when invoked.
thenCallRealImplementation()

/// Does nothing when invoked.
thenDoNothing()

The available methods depend on the stubbed method characteristics. For example you cannot use the thenThrow method with a method that isn't throwing or rethrowing.

An example of stubbing a method looks like this:

stub(mock) { stub in
  when(stub.greetWithMessage("Hello world")).then { message in
    print(message)
  }
}

As for a property:

stub(mock) { stub in
  when(stub.readWriteProperty.get).thenReturn(10)
  when(stub.readWriteProperty.set(anyInt())).then {
    print($0)
  }
}

Notice the get and set, these will be used in verification later.

Enabling default implementation

In addition to stubbing, you can enable default implementation using an instance of the original class that's being mocked. Every method/property that is not stubbed will behave according to the original implementation.

Enabling the default implementation is achieved by simply calling the provided method:

let original = OriginalClass<Int>(value: 12)
mock.enableDefaultImplementation(original)

For passing classes into the method, nothing changes whether you're mocking a class or a protocol. However, there is a difference if you're using a struct to conform to the original protocol we are mocking:

let original = ConformingStruct<String>(value: "Hello, Cuckoo!")
mock.enableDefaultImplementation(original)
// or if you need to track changes:
mock.enableDefaultImplementation(mutating: &original)

Note that this only concerns structs. enableDefaultImplementation(_:) and enableDefaultImplementation(mutating:) are different in state tracking.

The standard non-mutating method enableDefaultImplementation(_:) creates a copy of the struct for default implementation and works with that. However, the mutating method enableDefaultImplementation(mutating:) takes a reference to the struct and the changes of the original are reflected in the default implementation calls even after enabling default implementation.

We recommend using the non-mutating method for enabling default implementation unless you need to track the changes for consistency within your code.

Chain stubbing

It is possible to chain stubbing. This is useful for when you need to define different behavior for multiple calls in order. The last behavior will be used for all calls after that. The syntax goes like this:

when(stub.readWriteProperty.get).thenReturn(10).thenReturn(20)

which is equivalent to:

when(stub.readWriteProperty.get).thenReturn(10, 20)

The first call to readWriteProperty will return 10 and all calls after that will return 20.

You can combine the stubbing methods as you like.

Overriding of stubbing

When looking for stub match Cuckoo gives the highest priority to the last call of when. This means that calling when multiple times with the same function and matchers effectively overrides the previous call. Also more general parameter matchers have to be used before specific ones.

when(stub.countCharacters(anyString())).thenReturn(10)
when(stub.countCharacters("a")).thenReturn(1)

In this example calling countCharacters with a will return 1. If you reversed the order of stubbing then the output would always be 10.

Usage in real code

After previous steps the stubbed method can be called. It is up to you to inject this mock into your production code.

Note: Call on mock which wasn't stubbed will cause an error. In case of a spy, the real code will execute.

Verification

For verifying calls there is function verify. Its first parameter is the mocked object, optional second parameter is the call matcher. Then the call with its parameters follows.

verify(mock).greetWithMessage("Hello world")

Verification of properties is similar to their stubbing.

You can check if there are no more interactions on mock with function verifyNoMoreInteractions.

Argument capture

You can use ArgumentCaptor to capture arguments in verification of calls (doing that in stubbing is not recommended). Here is an example code:

mock.readWriteProperty = 10
mock.readWriteProperty = 20
mock.readWriteProperty = 30

let argumentCaptor = ArgumentCaptor<Int>()
verify(mock, times(3)).readWriteProperty.set(argumentCaptor.capture())
argumentCaptor.value // Returns 30
argumentCaptor.allValues // Returns [10, 20, 30]

As you can see, method capture() is used to create matcher for the call and then you can get the arguments via properties value and allValues. value returns last captured argument or nil if none. allValues returns array with all captured values.

3. Matchers

Cuckoo makes use of matchers to connect your mocks to your code under test.

A) Automatic matchers for known types

You can mock any object that conforms to the Matchable protocol. These basic values are extended to conform to Matchable:

  • Bool
  • String
  • Float
  • Double
  • Character
  • Int
  • Int8
  • Int16
  • Int32
  • Int64
  • UInt
  • UInt8
  • UInt16
  • UInt32
  • UInt64

Matchers for Array, Dictionary, and Set are automatically synthesized as long as the type of the element conforms to Matchable.

B) Custom matchers

If Cuckoo doesn't know the type you are trying to compare, you have to write your own method equal(to:) using a ParameterMatcher. Add this method to your test file:

func equal(to value: YourCustomType) -> ParameterMatcher<YourCustomType> {
  return ParameterMatcher { tested in
    // Implementation of equality test for your custom type.
  }
}

⚠️ Trying to match an object with an unknown or non-Matchable type may lead to:

Command failed due to signal: Segmentation fault: 11

For details or an example (with Alamofire), see this issue.

Parameter matchers

ParameterMatcher itself also conforms to Matchable. You can create your own ParameterMatcher instances or if you want to directly use your custom types there is the Matchable protocol. Standard instances of ParameterMatcher can be obtained via these functions:

/// Returns an equality matcher.
equal<T: Equatable>(to value: T)

/// Returns an identity matcher.
equal<T: AnyObject>(to value: T)

/// Returns a matcher using the supplied function.
equal<T>(to value: T, equalWhen equalityFunction: (T, T) -> Bool)

/// Returns a matcher matching any Int value.
anyInt()

/// Returns a matcher matching any String value.
anyString()

/// Returns a matcher matching any T value or nil.
any<T>(type: T.Type = T.self)

/// Returns a matcher matching any closure.
anyClosure()

/// Returns a matcher matching any throwing closure.
anyThrowingClosure()

/// Returns a matcher matching any non nil value.
notNil()

Cuckoo also provides plenty of convenience matchers for sequences and dictionaries, allowing you to check if a sequence is a superset of a certain sequence, contains at least one of its elements, or is completely disjunct from it.

Matchable can be chained with methods or and and like so:

verify(mock).greetWithMessage("Hello world".or("Hallo Welt"))

Call matchers

As a second parameter of the verify function you can use instances of CallMatcher. Its primary function is to assert how many times was the call made. But the matches function has a parameter of type [StubCall] which means you can use a custom CallMatcher to inspect the stub calls or for some side effect.

Note: Call matchers are applied after the parameter matchers. So you get only stub calls of the desired method with correct arguments.

Standard call matchers are:

/// Returns a matcher ensuring a call was made `count` times.
times(_ count: Int)

/// Returns a matcher ensuring no call was made.
never()

/// Returns a matcher ensuring at least one call was made.
atLeastOnce()

/// Returns a matcher ensuring call was made at least `count` times.
atLeast(_ count: Int)

/// Returns a matcher ensuring call was made at most `count` times.
atMost(_ count: Int)

As with Matchable you can chain CallMatcher with methods or and and. However, you can't mix Matchable and CallMatcher together.

Resetting mocks

Following functions are used to reset stubbing and/or invocations on mocks.

/// Clears all invocations and stubs of given mocks.
reset<M: Mock>(_ mocks: M...)

/// Clears all stubs of given mocks.
clearStubs<M: Mock>(_ mocks: M...)

/// Clears all invocations of given mocks.
clearInvocations<M: Mock>(_ mocks: M...)

Stub objects

Stubs are used for suppressing real code. Stubs are different from Mocks in that they don't support stubbing nor verification. They can be created with the same constructors as the mocked type. Name of stub class always corresponds to name of the mocked class/protocol with Stub suffix (e.g. stub of protocol Greeter is called GreeterStub).

let stub = GreeterStub()

When a method is called or a property accessed/set on a stub, nothing happens. If a value is to be returned from a method or a property, DefaultValueRegistry provides a default value. Stubs can be used to set implicit (no) behavior to mocks without the need to use thenDoNothing() like this: MockGreeter().spy(on: GreeterStub()).

DefaultValueRegistry

DefaultValueRegistry is used by Stubs to get default values for return types. It knows only default Swift types, sets, arrays, dictionaries, optionals, and tuples (up to 6 values). Tuples for more values can be added through extensions. Custom types must be registered before use with DefaultValueRegistry.register<T>(value: T, forType: T.Type). Furthermore, default values set by Cuckoo can also be overridden by this method. Sets, arrays, etc. do not have to be registered if their generic type is already registered.

DefaultValueRegistry.reset() returns the registry to its clean slate before the register method made any changes.

Cuckoo generator

Installation

For normal use you can skip this because the run script downloads or builds the correct version of the generator automatically.

Custom

So you have chosen a more complicated path. You can clone this repository and build it yourself. Take a look at the run script for more inspiration.

Usage

Generator can be executed manually through the terminal. Each call consists of build options, a command, generator options, and arguments. Options and arguments depend on the command used. Options can have additional parameters. Names of all of them are case sensitive. The order goes like this:

cuckoo build_options command generator_options arguments

Build Options

These options are only used for downloading or building the generator and don't interfere with the result of the generated mocks.

When the run script is executed without any build options (they are only valid when specified BEFORE the command), it simply searches for the cuckoo_generator file and builds it from source code if it's missing.

To download the generator from GitHub instead of building it, use the --download [version] option as the first argument (i.e. run --download generate ... or run --download 1.3.0 generate ... to fetch a specific version). If you're having issues with rather long build time (especially in CI), this might be the way to fix it.

NOTE: If you encounter Github API rate limit using the --download option, the run script refers to the environment variable GITHUB_ACCESS_TOKEN. Add this line (replacing the Xs with your GitHub token, no additional permissions are needed) to the script build phase above the run call:

export GITHUB_ACCESS_TOKEN="XXXXXXX"

The build option --clean forces either build or download of the version specified even if the generator is present. At the moment the run script doesn't enforce the generator version to be the same as the Cuckoo version. We recommend using this option after updating Cuckoo as well as if you're having mysterious compile errors in the generated mocks. Please try to use this option first to verify that your generator isn't outdated before filing an issue about incorrectly generated mocks.

We recommend only using --clean when you're trying to fix a compile problem as it forces the build (or download) every time which makes the testing way longer than it needs to be.

Generator commands

generate command

Generates mock files.

This command accepts options that can be used to adjust the behavior of the generator, these are listed below.

After the options come arguments, in this case a list (separated by spaces) of files for which you want to generate mocks or that are required for correct inheritance mocking.

--output (string)

Absolute path to where the generated mocks will be stored.

If a path to a directory is supplied, each input file will be mapped to its own output file with mocks.

If a path to a file is supplied, all mocks will be generated into this single file.

The default value is GeneratedMocks.swift.

--testable (string)[,(string)...]

A comma separated list of frameworks that should be imported as @testable in the mock files.

--exclude (string)[,(string)...]

A comma separated list of classes and protocols that should be skipped during mock generation.

--no-header

Do not generate file headers.

--no-timestamp

Do not generate timestamp.

--no-inheritance

Do not mock/stub parents and grandparents.

--file-prefix (string)

Names of generated files in directory will start with this prefix. Only works when output path is directory.

--no-class-mocking

Do not generate mocks for classes.

--regex (string)

A regular expression pattern that is used to match Classes and Protocols. All that do not match are excluded. Can be used alongside --exclude in which case the --exclude has higher priority.

-g or --glob

Activate glob parsing for specified input paths.

-d or --debug

Run generator in debug mode. There is more info output as well as included in the generated mocks (e.g. method parameter info).

version command

Prints the version of this generator.

help command

Display general or command-specific help.

After the help command you can specify the name of another command for displaying command-specific information.

Objective-C Support

Cuckoo subspec Cuckoo/OCMock brings support for mocking Objective-C classes and protocols.

Example usage:

let tableView = UITableView()
// stubbing the class is very similar to stubbing with Cuckoo
let mock = objcStub(for: UITableViewController.self) { stubber, mock in
  stubber.when(mock.numberOfSections(in: tableView)).thenReturn(1)
  stubber.when(mock.tableView(tableView, accessoryButtonTappedForRowWith: IndexPath(row: 14, section: 2))).then { args in
    // `args` is [Any] of the arguments passed and the closure needs to cast them manually
    let (tableView, indexPath) = (args[0] as! UITableView, args[1] as! IndexPath)
    print(tableView, indexPath)
  }
}

// calling stays the same
XCTAssertEqual(mock.numberOfSections(in: tableView), 1)
mock.tableView(tableView, accessoryButtonTappedForRowWith: IndexPath(row: 14, section: 2))

// `objcVerify` is used to verify the interaction with the methods/variables
objcVerify(mock.numberOfSections(in: tableView))
objcVerify(mock.tableView(tableView, accessoryButtonTappedForRowWith: IndexPath(row: 14, section: 2)))

Detailed usage is available in Cuckoo tests along with DOs and DON'Ts of this Swift-ObjC bridge.

So far, only CocoaPods is supported. To install, simply add this line to your Podfile:

pod 'Cuckoo/OCMock'

Contribute

Cuckoo is open for everyone and we'd like you to help us make the best Swift mocking library. For Cuckoo development, follow these steps:

  1. Make sure you have latest stable version of Xcode installed
  2. Clone the Cuckoo repository
  3. In Terminal, run: make dev from inside the Cuckoo directory
  4. Open Cuckoo.xcodeproj
  5. Select either Cuckoo-iOS or Cuckoo-macOS scheme and verify by running the tests (⌘+U)
  6. Peek around or file a pull request with your changes

The project consists of two parts - runtime and code generator. When you open the Cuckoo.xcodeproj in Xcode, you'll see these directories: - Source - runtime sources - Tests - tests for the runtime part - CuckoGenerator.xcodeproj - project generated by make dev containing Generator source code

Thank you for your help!

Inspiration

Used libraries

License

Cuckoo is available under the MIT License.

Github

link
Stars: 1233

Dependencies

Used By

Total: 0

Releases

New Release – 1.3.2 - 2020-02-23 21:25:57

  • Fix image not found error for iOS 13 and beyond.

New Release – 1.3.1 - 2020-02-23 18:53:03

  • Swift Package Manager support
  • Added tvOS target (thanks @rodrigoff).
  • Fixed accessibility to match enclosing container.
  • Restructured README.

New Release – 1.3.0 - 2019-11-06 13:37:50

  • Fix closure generation where explicit return type is required in withoutActuallyEscaping since swift 5.1 (XCode 11)
  • Switch swift_version to 5.0 for Cocoapods

New Release – 1.2.0 - 2019-09-11 13:56:38

Features

  • Objective-C mocking! Mock system classes/protocols as well as dynamic Swift classes. This is an optional subspec Cuckoo/OCMock.
  • Convenience matchers for sequences and dictionaries. No need to use equal(to:) anymore, passing the Array/Set/Dictionary itself is enough from now on!

New Release – 1.1.1 - 2019-07-30 14:25:05

  • Fix property, initializer, and function accessibility in public protocols.

New Release – 1.1.0 - 2019-07-22 11:15:13

Features:

  • Add a simple type guesser based on assigned value.

Fixes:

  • Fix accessibility problems.

New Release – 1.0.6 - 2019-05-29 18:11:14

  • Fix a bug where adding a private name to a function made it generate twice and fail the compilation.

New Release – 1.0.5 - 2019-05-26 13:41:30

  • Fix generic protocol generation and type erasure with multiple methods of same name.
  • Exit run script with error if it fails to get generator download URL.

New Release – 1.0.4 - 2019-05-17 10:23:13

  • The run script doesn't use realpath command anymore because it's not available by default on Mac OS.
  • Remove redundant stubbing of optional classes.

New Release – 1.0.3 - 2019-05-16 16:53:41

  • Add support for optional read-only properties.

New Release – 1.0.2 - 2019-05-16 11:41:53

  • Fix where clause that doesn't work in Swift 4.
  • Fix some run script bugs.

New Release – 1.0.1 - 2019-05-15 15:51:25

  • Fix any() not working anymore by itself with optional parameters in functions.

New Release – 1.0.0 - 2019-05-14 16:47:10

Features:

  • Generics is now fully supported! This includes generic classes, protocols, and methods.
  • Dictionary matching out of the box.
  • Better closure matching. Now allowing up to 7 parameter closures.
  • rethrows functions now work properly.
  • Classes marked final are automatically ignored.
  • Allow non-optional values to be passed as matchers for Optionals just like in normal Swift code.
  • Add support for inout method parameters.

Fixes:

  • Update the build_generator script to work with Swift 5.
  • Fix not being able to put Optional into functions accepting Optionals.
  • Accessibility of variables and functions in public classes are now public as well.

New Release – 0.13.0 - 2019-05-06 08:31:38

  • Update cocoapods.
  • Fix warnings when using Swift 5.0
  • Fix errors when using Swift 5.0
  • Improve Xcode 10.2 compatibility.
  • Update FileKit reference

New Release – 0.12.1 - 2019-02-23 15:39:07

  • Add class accessibility support.
  • Add support for attributes (e.g. @available).
  • Add support for subimport (e.g. import struct UICat.Food).
  • Add --clean option to the run script to always build or download the generator (promptly forget to add its documentation to README.md).
  • Ignore final classes (because we mock by inheritance).
  • Smaller fixes and improvements in the whole project.

New Release – 0.12.0 - 2018-10-09 12:11:28

  • Add first draft of a new Mock initialization DSL.
  • Add enableDefaultImplementation to protocol Mock.
  • Reintroduce support for pre-0.11.0 Cuckoo spies.
  • Add regular expression class and protocol matching.
  • Add glob switch that parses input paths as globs enabling for easier project scaling.
  • Build generator by default. Download using --download [VERSION] option.
  • Modify the run bash script to allow the user to build rather than download the cuckoo_generator.
  • Add a debug flag that generates general info above methods when used.
  • Fix escaping closure (crashing in Xcode 10).

New Release – 0.11.3 - 2018-04-05 15:14:10

  • Make sure we keep the cuckoo_generator in the Pods/Cuckoo dir.

New Release – 0.11.2 - 2018-04-04 09:27:20

  • Fix handling of access_token and username in Fastfile.
  • Make sure we bundle Swift runtime with the released generator.
  • Disable bitcode

New Release – 0.11.0 - 2018-03-23 20:04:11

  • Add test for sub protocol method
  • The sort of input files occurred to soon * The files input via options are mapped to Path objects then sorted. This actually happened too soon, since the array is then converted to a Set, then converted back to an Array. The Set conversion changes the order (since it is unordered) and those we lost the effect of the sort. I move the sort to the correct place, which is on the outermost Array so that the inputPathValues array is now correctly sorted.
  • Upgrade Fastfile and podspec. run downloads the latest generator if it's deleted.
  • Make the script a bit more resilient.
  • Fix changelog creating and make commit message ignoring broader.
  • Update Gemfile.
  • Add initial deployer script for deploying release drafts to github.
  • fix(readme): fix typos and grammar
  • doc(readme): add precision on custom matchers
  • Fix CI-status badge
  • Updated readme run script
  • Make the bash script safe to use with names that contain spaces.
  • Fixes a regression introduced in 96ebbbf * There was an attempt to make the file order deterministic, but the sorting that was added only worked if all mocks were generated in a single file. If generated to a path, which creates a file per mock, the filenames and the file contents did not match. Solution was to sort the set of paths passed in as options instead, moving the sorting a little earlier than before.
  • Fix sameInstance(as:) ambiguous reference compile-time error.
  • Added test-cases for excluding Classes and Protocols from Mock stub generation
  • Added ParameterMatcher for (optional) throwing closures and optionals, e.g. anyThrowingClosure(), anyOptionalThrowingClosure and null() Added Acceptance test for inheritance stubbing and verifying
  • Adding support for overloaded method names
  • Add a few more tests.
  • Change get in property verification to method instead of a property.
  • Remove TemplateEncoder and change Spy behavior.
  • Don't test iOS for now.
  • Disable signing.
  • Remove workspace and improve project setup.

0.6.0 - 2016-07-02 13:13:38

  • Added release notes
  • Added stub resetting
  • Added thenCallRealImplementation
  • Added argument capturing
  • Added verifyNoMoreInteractions
  • Added on going stubbing
  • Added thenDoNothing

Developer experience - 2016-06-15 09:13:51

In this release we added a run script that you can use to easily run Cuckoo generator with ease. We also changed the Cuckoo Generator so that it no longer contains all the different generator versions, which means easier updating and adding new features!

Class and property mocking - 2016-02-11 21:56:05

In this release we bring you support for mocking classes and properties (both in classes and protocols). To use this functionality, you also need Cuckoo Generator 0.3.0 (if you use Run Script provided in README, it will install itself).

Documentation, yay! - 2016-01-26 00:29:38

Added documentation to methods meant to be used in tests. Also see the README file for example usage. More documentation coming soon!

Protocol mocking - 2016-01-26 00:28:37

First release supporting protocol mocking.