Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
Kotest
Powerful, elegant and flexible test framework for Kotlin with additional assertions, property testing and data driven testing
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
As you can see, I create mockUsersRepository object using mock( function. Then, in setup() method, I set up this repository in such a way so that it would return a list of hardcoded values. After this, on top of everything else, I check if, for mockUsersRepository object, getUsers method was called with verify function, in the test method. It’s important to note that Mockito is a very old framework and was originally written for Java. When Kotlin appeared, it turned out that out of the box this framework can work with some limitations, which is why an extension, mockito-kotlin, was released. The example above was written with it. Another Mockito’s limitation was that it was impossible to mock final classes and static methods, and all classes are final by default in Kotlin. Currently, this is solved through mockito-inline but, before, it was a serious limitation. In respect to Java development, there was and is an alternative for Android developers, PowerMock.
Mockk is a rather new framework; it was originally designed for Kotlin, although it supports Java as well. Before mockito-kotlin was released, using Mockk was much easier and beneficial for Kotlin developers, but right now both these frameworks have nearly the same set of features and similar syntax. For example, assume that our function loadUsers is no longer synchronous, but rather suspended:
Much of this is now available in Mockito. Even more - naturally Kotlin doesn’t have static methods, and it’s a good practice not to create them. Ideal code is code that follows the SOLID and Clean Architecture principles, which means it can be easily mocked and tested. Therefore, we, Android developers, don’t need PowerMock’s special features but it’s important to remember that such frameworks exist. Another Mockito’s limitation concerns work with coroutines and flows. In such cases, once again, mockito-kotlin as well as third-party libraries like turbine will help you out. This being said, I’d like to tell you about another alternative to Mockito, which is Mockk.
The describe-it style is mainly used to write Spek tests. describe structure allows us to create a group of tests describing a specific method, and, in it, a specific scenario for the method is written. But it is also possible to use the GivenWhenThen style. Unfortunately, the framework doesn’t have embedded coroutine support, so we have to always use runBlockingTest { } for suspended functions. There is a ticket with this feature request on Github, but it seems it was never completed.
As a matter of fact, in the previous examples, we have shifted a bit away from the TDD standards in the meaning that we test not only the operability of our code, but rather check if the code runs according to certain specifications (Given/When/Then). These specifications are our tests, and the syntactic sugar in the form of the possibility to give clear names to the tests using DisplayName and the grouping of the tests by a set of similar attributes helps us clearly formulate these specifications. There is an entire family of frameworks in different languages that allow us to create such specifications: for Java it is Spock, for Ruby—RSpec, and for Kotlin—Spek and Kotest frameworks. Below, I will go into more detail about them.