Testing - Java SDK

Application Context

To initialize the SDK, you'll need to provide an application or activity context. This isn't available by default in Android integration tests. However, you can use Android's built-in testing ActivityScenario class to start an activity in your tests. You can use any activity from your application, or you can create an empty activity just for testing. Call ActivityScenario.launch() with your activity class as a parameter to start the simulated activity.

Next, use the ActivityScenario.onActivity() method to run a lambda on the simulated activity's main thread. In this lambda, you should call the Realm.init() function to initialize the SDK with your activity as a parameter. Additionally, you should save the parameter passed to your lambda (the newly created instance of your activity) for future use.

Because the onActivity() method runs on a different thread, you should block your test from executing further until this initial setup completes.

The following example uses an ActivityScenario, an empty testing activity, and a CountDownLatch to demonstrate how to set up an environment where you can test your Realm application:

Looper Thread

Realm functionality such as Live objects and change notifications only work on Looper threads. Threads configured with a Looper object pass events over a message loop coordinated by the Looper. Test functions normally don't have a Looper object, and configuring one to work in your tests can be very error-prone.

Instead, you can use the Activity.runOnUiThread() method of your test activity to execute logic on a thread that already has a Looper configured. Combine Activity.runOnUiThread() with a CountDownLatch as described in the delay section to prevent your test from completing and exiting before your logic has executed. Within the runOnUiThread() call, you can interact with the SDK just like you normally would in your application code:

Delay Test Execution While Async Calls Complete

Because the SDK uses asynchronous calls for common operations such as database queries, authentication, and function calls, tests need a way to wait for those async calls to complete. Otherwise, your tests will exit before your asynchronous (or multi-threaded) calls run. This example uses Java's built-in CountDownLatch. Follow these steps to use a CountDownLatch in your own tests:

1. Instantiate a CountDownLatch with a count of 1.

2. After running the async logic your test needs to wait for, call that CountDownLatch instance's countDown() method.

3. When you need to wait for async logic, add a try/catch block that handles an InterruptedException. In that block, call that CountDownLatch instance's await() method.

4. Pass a timeout interval and unit to await(), and wrap the call in a Assert.assertTrue() assertion. If the logic takes too long, the await() call times out, returning false and failing the test.

The following example demonstrates the use of a CountDownLatch to wait for authentication and opening a realm asynchronously on a separate thread:

Testing Backend

Applications that use an App backend should not connect to the production backend for testing purposes for the following reasons:

• you should always keep test users and production users separate for security and privacy reasons

• tests often require a clean initial state, so there's a good chance your tests will include a setup or teardown method that deletes all users or large chunks of data

You can use environments to manage separate apps for testing and production.

Testing Atlas Cluster

Applications that use Sync or MongoDB queries may read, write, update, or delete data stored in connected Atlas clusters. For security purposes, you shouldn't store production data and testing data on the same cluster. Additionally, tests may require schema changes before those changes are gracefully handled in your production application. As a result, you should use a separate Atlas cluster when testing your application.

Full Example

The following example shows a full Junit instrumented androidTest example running Realm in integration tests:

Full Example

The following example shows a full JUnit test example mocking Realm in unit tests. This example tests an activity that performs some basic Realm operations. The tests use mocking to simulate those operations when that activity is started during a unit test: