That can create quite a bit of boilerplate code, but at the same time allows you to fine-tune code to your needs.Īfter this, tests themselves are quite trivial: in the first we verify logic in initialize method, in the second we verify the update method updates UI correctly. This is the second drawback of the method - since there is no “real” layout in tests we need to mock every single UI component we want to verify in tests. Here we initialize mocks declared above with annotation, create a subject for tests with spyk and then set up views for our subject with mocks. Next, let’s look at the setUp method at the top of the suite. In the real scenario, you probably would have those methods in the base abstract class for all View tests.
In first we make sure LayoutInflater is mocked (so we can mock om method later on) and in the second one, we unmock it to make sure other tests are not screwed. As you can see, we define two functions: to run before the suite and to run after it. I think it’s better to start from the bottom, where the companion object is. I will start with the presentation of the code since there is not a lot of it:
Note that the technique is applicable to Activity, but, since you can’t create an instance of Activity manually, you still will need either Robolectric or instrumentation to provide you with that, which removes much of the benefits of the approach. The solution I want to present utilises custom Android view and Mockk, which allows us to achieve exactly what we want - ability to check that methods were called, without dragging the whole Android framework to tests with us. And well, if it doesn’t, it is nothing you can fix directly anyway, you can only work around it. We don’t need to check that our view became red since we assume that the framework works correctly. What does it mean? It means that if we can make sure that our code called: The main idea is that we don’t need to check if our UI is displayed correctly (most of the time) what we really need is to make sure that we’ve set proper variables or called proper functions with proper arguments. If you would rather just play with code here’s the repo that contains all the code used in this article. I want to propose an alternative solution, which, while not being applicable everywhere, might provide a faster, better and more stable option for UI testing. Robolectric improves the situation quite a bit but still has its own problems. In this short article, I want to propose a method on unit testing an Android View.Īnybody who ever wrote UI tests knows it’s quite slow (both in terms of implementation and in terms of execution) and prone to errors and number of problems (especially running on CI).
0 kommentar(er)
