iOS unit test mocking using SwiftyMocky
Tags: ios, swift, testing, testdev
Published: 2022-11-27 16:37:24

Swift was designed to be safe — supporting read-only reflection. Thus, there’s no way to modify your program at runtime. Overall, it’s good, the code is executed as expected, and other components cannot change it. But leading back to our topic, all mocking frameworks are built on reflection to be able to change classes, types, and objects on runtime.

This language needs its superheroes to write testable code, and we know them well — protocols and extensions! No matter what implementation it is — class, enum, or struct — the purpose of protocols remains — to define abstractions and add new functionality to types, even ones we don’t owe.



**What we can do to mock?**

Use meta-programming to generate complete mock implementation.

They are many libraries doing the mock job for the unit testing, most poplar are Cuckoo and swifyMocky.

In this article, I will give overview on how we can do the mocking using SwiftyMocky.

## SwiftyMocky
[](https://github.com/MakeAWishFoundation/SwiftyMocky
)

**Advantages**

- Automatically mock Swift protocols
- Support generics
- Straightforward setup and lightweight
- Good documentation
- Nice and easy syntax (that utilizes auto-complete)

**Mock generation**

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


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nd4dau49ik0luuw7zuzr.png)

**Stubbing**

- 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)

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dh0ycwghce93g05l46rx.png)

**Spying**

- 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 mocks has perform method (accessible both as instance method or global function), with easy to use syntax, allowing to specify closure, that will be executed upon stubbed method being called


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/07lybg1gkde44vwwlaod.png)


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5gxvxxum7f0lwetrelq5.png)


**Autocomplete**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/aeia7kuuejeiyqo05jye.gif)


**Setup**

- Install using Cocoapods

- Instal CLI for easy mock generation
   > swiftymocky setup # if you don’t have a Mockfile yet

   > swiftymocky doctor # validate your setup

   > swiftymocky generate # generate mocks

- Mocks generation is based on Mockfile.yml file with possibility to exclude swift lint rules using excludedSwiftLintRules


## Conclusion

Not so many tools we, as developers, have for mocking on Swift, with some strict boundaries due to language limited runtime access. And here we come to the critical question — use or not to use external frameworks for mocking.

Well-known Uncle Bob keeps not using them as much as possible; he says: “_The point at which you start to need a mocking framework is the very point at which the coupling between your tests and code is getting too high. After that, however, You should strive to keep the coupling between your code and tests low enough that you don’t need to use the mocking framework very often._”

**Thank you for reading! If you liked this article, please clap so other people can read it too :)**
**Happy coding :v:**

Reach me out [here](https://marwanayman.com/)