BusyBee is an alternative API for IdlingResources in Espresso tests. You can use BusyBee instead of CountingIdlingResource to get better log messages and improve your ability to debug problems related to IdlingResources.
BusyBee is meant to be used with Espresso. You use BusyBee inside the "app under test". It allows the "app under
test" to tell Espresso when it is busyWith
an operation and, conversely, allows the app to tell Espresso when the
operation is completed
. Tracking busyWith
/completed
helps your Espresso tests be fast and reliable.
If you write Espresso tests, proper use of the IdlingResource API is critical for ensuring that your tests are fast and reliable. IdlingResource can be hard to use correctly and it can be hard to understand what is happening with your IdlingResources when you are debugging problems with your tests. That is where BusyBee comes in.
Comparison with CountingIdlingResource
In some ways, BusyBee is similar to CountingIdlingResource, but it does have some notable advantages:
- Rather than track only the number of operations in progress, BusyBee keeps track of the set of operations currently in progress. In progress operations are represented by a Java object, which could be a string, request object, etc. This allows for easier debugging, as it allows you to inspect the set of in progress operations across the whole app.
- When Espresso times out because the app is busy, your logs can show the list of in progress operations.
- BusyBee lets you separately enable/disable tracking of specific categories of operations (e.g.
NETWORK
operations) - The
BusyBee#completed(thing)
method is idempotent (CountingIdlingResource#decrement
is not). This is useful when you have unreliable/multiple signals (e.g. WebView) to tell you that an operation has completed. Also, you cancompleted(thing)
even if you never werebusyWith(thing)
Trade-off: While there are a number of advantages listed above, the downside of BusyBee
(and
CountingIdlingResource
) is that you are modifying your app under test for purely testing purposes.
Include the BusyBee dependencies in your build.gradle
files. When tests are not running, the no-op implementation
is automatically used to minimize overhead of BusyBee (since it is only needed during tests).
Find the latest version on Maven Central
Required: For Android modules:
implementation 'io.americanexpress.busybee:busybee-android:$version'
Optional: Only needed, if you want to use BusyBee in a non-Android module:
implementation 'io.americanexpress.busybee:busybee-core:$version'
BusyBee releases are available on Maven Central.
repositories {
exclusiveContent {
forRepository { mavenCentral() }
filter { includeGroup("io.americanexpress.busybee") }
}
}
On each merge to main
, a -SNAPSHOT
version is published to https://s01.oss.sonatype.org/content/repositories/snapshots/
Inside your app, tell BusyBee
what operations your app is busyWith
, and when that operation is completed
.
class BackgroundProcessor {
private final BusyBee busyBee = BusyBee.singleton();
void processThing(Thing thing){
// Espresso will wait
busyBee.busyWith(thing);
try {
thing.process();
} finally {
// Espresso will continue
busyBee.completed(thing);
}
}
}
That's all! Now Espresso will wait until your app is not busy before executing its actions and assertions.
Assigning a Category
to your operations is an advanced feature of BusyBee
. By default, all operations are in the
GENERAL
category. But, you can also add operations in other categories such as NETWORK
. You can toggle tracking for
any category with payAttentionToCategory
/ignoreCategory
. When a category is being "ignored" then Espresso will not
wait for operations in that category.
For example, you might want to perform actions on your UI or assert things about your UI while a network request is
still in progress. In this case, you don't want Espresso to wait for the network requests to complete, but you still
want Espresso to wait for other operations in your app. To accomplish this, you would use
busyBee.ignoreCategory(NETWORK)
, then perform actions and assertions on your UI, then call
busybee.payAttentionToCategory(NETWORK)
so Espresso will again wait for network operations to complete.
If you have an executor and you need Espresso to know the app is "busy" anytime that executor is executing something,
then you can wrap the Executor
with BusyBeeExecutorWrapper
. Operations executed with the wrapped Executor
will
cause BusyBee
to be "busy" while they are in progress.
Executor backgroundTasks;
Executor busyBeeBackgroundTasks =
BusyBeeExecutorWrapper.with(busyBee)
.wrapExecutor(backgroundTasks)
.build();
busyBeeBackgroundTasks.execute(operation);
We welcome Your interest in the American Express Open Source Community on Github. Any Contributor to any Open Source Project managed by the American Express Open Source Community must accept and sign an Agreement indicating agreement to the terms below. Except for the rights granted in this Agreement to American Express and to recipients of software distributed by American Express, You reserve all right, title, and interest, if any, in and to Your Contributions. Please fill out the Agreement.
Any contributions made under this project will be governed by the Apache License 2.0.
The Android™ robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License. Android is a trademark of Google Inc.
This project adheres to the American Express Community Guidelines. By participating, you are expected to honor these guidelines.