From the course: Practical Test-Driven Development for Java Programmers

Reviewing fakes and tautologies

From the course: Practical Test-Driven Development for Java Programmers

Start my 1-month free trial Buy for my team

Reviewing fakes and tautologies

“

- [Instructor] Hello and welcome back once again. As we've just covered two important features of testing, stubs and mocks, I'd like to start this chapter by reviewing what we've learned so far. We use stubs and mocks when the code we wish to test has some kind of external dependency that we need to override. Both stubs and mocks are our own mini implementations of the object that we are overriding. The idea then is that stubs are used so the objects return some kind of data so that our code can execute and the primary use then of a stub is to test the outcome of the method that we are calling. It's used to validate some form of data. Mocks, on the other hand, are used to check whether or not objects are being used. Their purpose is to test behavior. Now although mocks and stubs are different, in terms of their functionality using Mockito, you can actually create a mock for every object. And in fact, we'll do that shortly. We'll change the stub we built before into a Mockito mock object. As we'll see doing this is less effort than writing a stub in the way that we did. In some testing frameworks, there are separate objects for mocks and stubs. If the framework you are using does provide these, then you're generally best advised to use stubs if you're not testing behavior. As they will be a lighter weight option and your tests may run a little bit faster. Mockito only gives us a single object type which is the mock so we will create everything as a mock in Mockito. Now you might find people refer to another object type as well stubs and mocks. And in particular, you may come across fakes or dummies. These are even lighter weight versions of stubs. The use case for a fake or a dummy is normally when you need to override something but you have no interest in the thing that you are overriding. Here's a good example. Suppose that our tests call a method which includes the following line of code. Our application is using some kind of logging system, maybe Log4j and within the test method, it's calling a method of the logging system to record that the method has been called. Now that might be quite useful in production but it might be annoying to have all of these method calls recorded in the log from our unit tests. So we might want to override this method to ensure that nothing gets written to the log when we're calling our unit test methods. Well, as I said, some frameworks provide a special object type specifically for this kind of example which they call a fake or a dummy. It's a really light weight object which accepts any method calls, it doesn't ever return any data and we don't need to provide or in fact we can't provide any kind of implementation. The idea here is that if we can override this logger object with a fake or a dummy, then any method call to this object will simply get ignored. Well, in Mockito, you can achieve this same effect, you still use the mock object but the idea is that we will create a mock, we'll insert it into the class, but we won't provide any kind of implementations for any of its objects. We simply create the mock and insert it in. And in Mockito, that effectively achieves the idea of providing a fake or a dummy. So now this gives us three levels of objects that we could inject into our code from a unit test. We've got the fake or the dummy, which is when you want to override something, but you have no care about it at all, its presence is just needed either to make your code work or to avoid some kind of effect that your code might have that doesn't impact your test but you don't want that effect to happen somewhere else. And in Mockito, we do that simply by creating the mock object. We have stubs and these are useful when you want to override something which will impact your test but is not the critical part of the thing that you are trying to test and actually you're trying to test some kind of data or term. And in Mockito, we'll achieve that by creating the mock object but giving it some kind of implementation with the when.thenReturn construct. And finally, there's the mock where we want to know whether or not a method was called. And with that, we created in Mockito by using the mock followed by a verify on the method that you're trying to check whether or not it has been called.

Contents