Is running Espresso tests with Mockito possible (without dagger)?

Question

Is it possible to use Espresso with Mockito? I have an App where we call the API 2 times appart from authentication and we are trying to use Espresso with Mockito, to mock several methods close to UI. There is no dagger or any other dependency injection tool in the project and also, no unit tests.

I have already worked with Espresso on another, where we mocked the API with WebMockServer. The App had a lot of networking and this was great, we were able to test everything. Now, I do not get to mock a single thing.

Answer 1

Espresso is a UI testing framework, Mockito is a mocking framework. They work fine together.

I think the question you're asking depends more on the difference between white box testing and black box testing . In working with the application UI, Espresso is very capable of both white-box testing and black-box testing; you can write Espresso tests against an application without editing or accessing its internals (black box), or you can interact with the UI while being aware of the internals and reconfiguring them for testing purposes (white box). By contrast, Mockito provides mock implementations of your classes and interfaces, so in order for you to test with a Mockito-written implementation you'd need to reconfigure your application to consume it as in a white-box test.

You've described your application as lacking dependency injection and unit tests, which suggests that your components might not have been written with the configurability or testing seams in mind. You would need a seam like that to allow replacing your implementation with WebMockServer or a Mockito-provided implementation.

For a quick and hacky solution testing seam, you could simply make a public field on the Activity, Fragment, or View that you're trying to test, allowing you to replace that implementation from your test. You would need to change your code to accept the test-double value in the field rather than creating its own implementation. For an Activity or Fragment, you could get to the field using your own implementation of ActivityScenario.ActivityAction and then performing that onActivity as in the sample ; for views you could similarly write a ViewAction and then perform it onView the same way. Replace the field with your own implementation and you're good to go.

Of course, there are hazards with this approach: From a technical standpoint, the Activity can be recreated at will, so your implementation replacement may be short-lived. Furthermore, this may look less clean, because you're violating encapsulation to some degree: Your components are now allowing anyone to edit one of their fields, which is correct, because that's exactly what your test would be doing. This too is solvable: If the above hacky technique proves useful you might start abstracting away some of the view logic or activity logic to a replaceable implementation in a global singleton-style service, or from a field on the Application itself: in a broad sense, even without a formal framework, you'd be injecting a dependency .