Posted on

Android Testing pt 2 | Instrumented MediumTests

android instrumented tests

Designed by Freepik

This is the first post of us writing instrumented tests. Today we’ll work with Medium Tests

Medium Tests

Those are tests that run on your Android device, but don’t launch any activity, don’t have any UI. Unlike local tests – they have access to Android framework, so you can test some of your code that relies on Android framework, without the need of using Mockito or Robolectric

Those tests go into src/andoridTests, unlike local tests that are in src/tests

Integrated and instrumented come along together in Android testing, but those have different meaning

Integrated test is the one that relies on several elements (classes for example), so unlike with unit testing, where you’d mock that class – with integrated test you just use it

And instrumented tests are the ones that run on your Android device

And one interesting example I’ll show is with Parcelable. If you don’t know, Parcelalbe is an Android-specific way of marshaling POJO’s, like JDK’s Serializable. You can read more here

Now since it’s not automated as Serializable – you need to implement it yourself. Sure, there’re libraries that make your work easier, but let’s talk about our own implementation

TDD Approach

If you do apply TDD principles in your development – that’s awesome. Basically before writing your parcelable implementation you write tests for them. And after a while, when your model changes and you need to add extra fields – you’ll write tests first, again. No problem in this case

And User model


And then every time you want to add a new field – you add a new test assertion first

Relying on Equals

You can also rely on #User.equals method for testing. And basically moving verification logic from test to model itself for each field. And I don’t think it’s a very readable approach. Simply because you can forget about updating equals method when updating your test/adding new fields

Lazy Approach

What if you’re not a TDD guy or might just not trust yourself to update tests each time you change your model? Check an automated solution I came up


This is an auxiliary test that simply checks if all fields of a given object are not null. The best thing about it is that it uses reflection – meaning it’s completely automated. So let’s say you added a new field, but forgot to implement Parcelable part – this test will fail. Just to point you out to an error

Of course, it does not verify correct implementation of your Parcelable. You still need to write comparison test to be completely sure. This non null assertion works even for Java primitives and includes all fields from all parents, so it’s bulletproof

And definitely, for Parcelable you might consider using some libraries, but it’s just an example of how you can use instrumented tests.With Medium Instrumented tests you don’t see anything opened on your phone, in fact, you can even have your screen off during tests

In the next post, we’ll start UI testing with Espresso, so stay tuned. You can get the source code here