In RxJava 2, there’s this concept of
Disposables. They’re useful when e.g. you make a long-running HTTP request, but as the request is still in progress you are no longer interested in the results of that request. This might look like this in code:
I was playing around with
Disposables by calling
dispose() on different reactive chains with various operators used and I was actually surprised with the results. Therefore I decided to share the results in this article 🤓
All the code referenced in this article is available at the…
At StepStone, we’ve been using instrumentation tests to add that extra layer of protection in our apps for about 3 years now. While writing this kind of tests isn’t rocket science, having a stable & efficient CI environment is a different story… In this article I would like to present what were the issues we’ve encountered with UI tests in our in-house setup and why we’ve decided to migrate to Bitrise.io.
Recently, when writing integration tests with Robolectric on Android I came across a situation where, at some point, one of my tests would freeze for about 10 minutes when it was executed on a CI machine. This was a very strange behaviour as I didn’t change the test logic nor the class under test. To make matters worse, the test was not hanging on my local machine and I wasn’t able to reproduce it.
In this article, I’ll explain how to tackle this kind of situations when running any tests on CI machines (assuming you can connect to the machine…
With the rise of AndroidX Test library came a unified approach for writing Robolectric and instrumentation tests. Previously, to manage Activity lifecycle we had to use an
ActivityTestRule in Android Test Support Library and an
ActivityController in Robolectric. Now, there’s a single API for that called
ActivityTestRule is deprecated now and will be removed in favor of
In this article, I’ll show how to use this API in a number of different scenarios in Kotlin.
ActivityScenario— the basics
To get started we need to add AndroidX Core KTX library to our Gradle dependencies e.g.
Injecting dependencies into
Fragment classes has always been less than ideal (to say the least) when compared to other “regular” classes. With Dagger 2 in Kotlin, you would rather prefer to inject it via a constructor so that the dependencies are stored as
private properties like this:
but had to end up with something like this instead:
All dependencies are
public which is not ideal (you can make them
protected at most). Also, our
Fragment needs to extend
DaggerFragment or implement the same behaviour.
Just starting with instrumentation tests on Android? Or maybe you’ve written lots of them, but for some reason they keep on failing from time to time and it’s starting to REALLY get on your nerves?
Hopefully the tips below will make your life easier (TL;DR section at the very bottom of the article 😉).
Because Google recommends it 😏
Turn off animations on your test device — leaving system animations turned on in the test device might cause unexpected results or may lead your test to fail. …
There are many reasons why you should at least consider splitting your monolithic application into smaller modules. You might be seeking for build time improvements, Google Play Instant support (previously known as Instant Apps) or better separation of concerns. I’m not going to go into details about how to actually modularize your app as there’s already a ton of useful articles available (links at the bottom). This article focuses on how to deal with library modules which require flavors.
OK, so let’s say that you already have your app nicely divided into separate modules. Build time’s great, developing new features…
If you have any kind of tests then at some point they’re bound to fail. And usually it’s a good thing as they will detect bugs in your app 😃
The thing with Android instrumentation tests is that sometimes even though you have the stack-trace of what failed, it might be difficult to wrap your head around what’s the actual cause of failure. It’s even harder when your tests get executed on CI and you don’t see them failing right in front of your eyes so to speak. …
This article focuses on different types of use cases/interactors which we are using in our Android app. Use cases play an important role in Clean Architecture and I hope you’ll find our implementation useful!
A few notes before you start… As this is just a sample app some stuff is missing for simplicity e.g. handling screen rotations, avoiding code duplicates, having an actual DB connection/networking API. Please keep that in mind when browsing this code.
Enough with the excuses though…
There’s a bunch of articles which will explain this way better than I ever could:
In a nutshell each class…
Recently, we started using Android Test Orchestrator at Stepstone to help us with our instrumentation tests. In this article I would like to explain what it actually is, what issues it solves and how to use it. I’ll also uncover some of the magic that it uses under the hood to achieve what it does.
Android Test Orchestrator (as explained in the doc referenced above) is a tool
which allows you to run each of your app’s tests within its own invocation of
Principal Android Developer at Stepstone — passionate about technology, Android geek, photography enthusiast.