Avoiding Mocks in ScalaTest

Many times people have asked me how do I do mocking when writing tests for Scala applications. Since testing is a great deal for us (see seems that mocking has to be an integral part of our testing technique, so let’s explore some thoughts on this area. Simplified Testing with ScalaTest and Custom Matchers ) Let’s start by showing a common problem that occurs to us every single day. Please, notice that the example could be very simplistic, but given a context, it can be extrapolated to everyday realistic problems. Our problem domain is the one related to Application User Manipulation. Let’s define some high-level abstractions from the very beginning. First, we have an interface that store and retrieve objects from some kind of storage. As you may see, this definition is very abstract, and we need, at some point, specializations of it. Now, we can define another abstraction closer to our domain. is the abstraction that represents how we are going to manage the users in our application. UserRepository At this point, we need to implement and it needs a concrete representation of to work with. UserRepository DB Let’s start by writing some tests. There is nothing unusual about this test. The only thing it does is make sure a user is recoverable once it has been added it. The problem with it is that it needs some instance of . DB At this point, we can add a mocking lib to our dependencies and start mocking ; but the question is if that is really necessary. DB What about if just implement a version of it we can use in our tests? Now, in our tests, we need to initialize before running them. InMemDB In some way, we are creating a real implementation of which is fine for many cases, but sometimes we want to have more flexibility and in here is where mocking libs shine. DB In this case, we don’t have to implement to use it. We can mock/simulate the behavior of it in the way we want. However, in order to setup the mocking, extra steps are required. DB Let’s write another test using this technique. In here we are testing that the predicate (user.name.length ≤ 3) is being executed. As you can see, it is not hard to set up these mocks, but it could also be another way to do the same without introducing extra dependencies to our tests. What about if we could write the same test in the following way. We can actually create an instance of and implement it inline. The drawback is that we need to have the other functions there as well, even when we are not using them. DB We can cheat around of this by creating another trait with default implementation and then using the new one within the tests. And now we can rewrite our test as follow. It is important to remember that in here we are not testing at all. All that matters here is to be able to successfully test . DB UserRepository There is at least one more way to replace for something we could use in . We could mix in with our test class. DB UserRepository DB In this particular way, we need to implement the functions inside our test class which makes it an instance of That is kind of the same we did with , but in this case, we don’t need an extra class, and the implementation is exactly what our test needs and nothing else. DB . DB UserDBForTesting Let’s look at another example that brings a different way of simulating/replacing implementation by using type classes and context. This is an abstract that we could implement with some kind of specialization, in particular for . type class Writer User The idea is that we could do the following function calls. In order to make this happens, we need to implement which is the one that actually writes down the to disk. Write[User] User Writing a User should never fail. The involved tests for can be done in multiple ways, probably integration tests are a good approach to this problem. However, from this layer up, we don’t have to deal with the disk anymore. We can simply replace the implementation of in our tests. Writer[User] put Suppose we have to write user manager that override user info in some context. The context itself does not have to be fixed. not only writes to disk, but also do other verifications on users. .replace Let’s see how a test for it looks like. Internally, should do at some point. replace The problem is that for testing we should not go to disk all at. We could simply replace calls for testing. A way to do it is by replacing the context that is selected during testing. UserManager .put And then we implicitly import mocking/simulating the dependency that the class under test ( ) has. TrueTestingUserStorage UserManager Going back to the question Well, I normally don’t. How do I mock? We just saw few different ways of replacing mocks. I don’t mock because I can’t ever remember the specifics of the framework; because people in the team have strong opinions about how to do mocking and each person has different preferences on frameworks. There is too much to consider so that complexity and decision taking is harder to deal with. I personally find easier to use pure Scala techniques to mimic implementations of test dependencies while keeping small builds and library dependencies. It looks like mocking makes its way when there is is a lot of state to be managed inside your application components. However, having pure functions and less state within our modules makes easier to test the different part of the application/modules. Sometimes it takes time to embrace pure functional programming, but one of the benefits it brings to the table is the simplicity of the tests around it. Scala mix in does the job just fine. Many people struggle with these ideas. Please, share what you think about it and how you do mocking and testing in general. I will be glad to learn more from the Community. Notice that we were using some testing techniques and Scala implicit as we discussed in a previous post (see Simplified Testing with ScalaTest and Custom Matchers )