Index:

1. London Tube Status App — setting up
2. London Tube Status App — gradle cleanup and dagger
3. London Tube Status App — Retrofit and API setup
4. London Tube Status App — wrapping up the data layer
5. London Tube Status App — domain layer
6. London Tube Status App — layouts and view model
7. London Tube Status App — MVP implementation
8. London Tube Status App — UI tests and going live
9. London Tube Status App — from dagger to koin
10. London Tube Status App — from MVP to MVVM
11. London Tube Status App — from Rx to Coroutines

Hello everyone, welcome to article number 8 on the series. In the last article, we wrote all our MVP implementation and got an app ready to publish. Well, today we’re going to do exactly that, but not until we writing some missing UI Tests for our screen (I promise it’ll be small 😃).

UI Tests

So, let’s start with the UI tests on our screen. We’re going to use espresso (the dependency is already in the project) with the help of another library called Kakao, which is in essence, a Kotlin DSL for Espresso written by the Android team at Agoda. Let’s start by adding the dependency for Kakao in our project:

We need to update our Dependencies.kt file and add the 2 lines above in the ProjectDependencies and Versions objects respectively. Then we need to add the dependency in our android-common.gradle so it’s available in all the Android modules (Yeah I know it’s just one 😃). Add the following line to testing dependencies section:

androidTestImplementation ProjectDependencies.kakao

That’s it, dependencies sorted, now let’s start writing some tests.

Kakao

As mentioned above, Kakao is just a Kotlin DSL to use with espresso, but it does make writing UI tests much easier and makes them much easier to read and understand as well. There are 2 main concepts in Kakao:

Screen: this is a class we create for the screen under test, and where we define the views from that screen that will be interacted during the tests.

KView: this as expected represent your screen view components, the ones that will be interacted during the tests.

These are the basics, you can check the documentation for more details but I think after seeing the examples below it’ll be more clear. Let’s start with the Screen instance for our StatusActivity:

Since we basically want the test that the list of status is displayed, we’ll need references for our RecyclerView and also for a single item on it, so we can test that we got the list correctly.

Apart from the RecyclerView items that need to be defined with their own class, most of the other views can just be instantiated like the recyclerView and the lineName views above. Not very complicated, right? Let’s move on to the actual tests:

In fact, it’s only one test function. A super simple one just to verify that our RecyclerView is displayed, contains 11 items, and the first item is also visible and has Bakerloo as line name. Super simple, right? And how good is this code compared to writing all the matchers in the traditional way? If you didn’t know Kakao, be sure to try it because as you can see makes writing and reading UI tests a much more pleasant experience.

Publishing time 🎉

Ok, now that we wrote our UI tests, let’s move on to the exciting part. Publishing our app in the Google Play Store. I won’t get into much detail here, there are better guides elsewhere this will be just the basics and to show what I got ready to put in there. So what stuff do we need? Apart from an app name and descriptions, we need a high-res icon, a feature graphic and a couple of screenshots of the app.

Done. And this is pretty much all we need regarding the Play Store listing. The rest is about answering some questions and filling some forms that are straightforward. After filling up all the required information and uploading these assets, all there’s left to do is to upload the actual APK and write some release notes.

So, let’s go and generate a signed APK for our app and then upload it to the Play Store. Again not going into much detail here as well. We need to go to Build -> Generate Signed APK and we get a window like this below:

If we don’t already have a key store, we need to create a new one to hold your APK signing key. After this, we can just pick Build Type release and then finish. The signed APK will be generated for us.

Now, all that’s left is to upload to the Google Play Store and release the app. So, let’s go to the App Releases -> Manage Production -> Create Release and upload the APK. After uploading we can go ahead and rollout our app into Production, we just need to write some release notes and push the mighty button:

Ok, apparently Google still want us to confirm we’re sure 😃 We are.

And that’s it the app is now rolled out to Production and available in the Google Play Store. Download it and give it a try:

And I guess that’s it for today, and also for this series. Now that the app is live we finished the journey. Hope you enjoyed this article and the series, and if you did, don’t forget to share some love (or 👏) and stay tuned. Not sure what I’ll write about next, but something will be out in 2 weeks to keep up with the challenge.

London Tube Status App — MVP implementation ⬅ PREVIOUS

NEXT ➡ London Tube Status App — from dagger to koin