From 70f6f72c9362251f9af424d1190b99403fb5e4ec Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ga=C3=ABtan=20Muller?= Date: Wed, 4 Sep 2024 08:27:14 +0200 Subject: [PATCH] Update the "Best Practices & Limitations" page (#301) --- docs/best-practices.md | 8 ++++---- docs/custom-test-runner.md | 11 +++-------- 2 files changed, 7 insertions(+), 12 deletions(-) diff --git a/docs/best-practices.md b/docs/best-practices.md index 62dbda1d2..ecbb57b33 100644 --- a/docs/best-practices.md +++ b/docs/best-practices.md @@ -2,13 +2,13 @@ ## Best Practices -**DO** test layout inflation in your Robolectric test and ensure that click listeners are set up correctly by testing the `Activity` and `Layout` interaction directly rather than mocking the `LayoutInflater` or providing an abstraction over the view. +**DO** test layout inflation in your Robolectric test and ensure that click listeners are set up correctly by testing the [`Activity`](https://developer.android.com/reference/android/app/Activity) and layout interaction directly, rather than mocking the [`LayoutInflater`](https://developer.android.com/reference/android/view/LayoutInflater) or providing an abstraction over the [`View`](https://developer.android.com/reference/android/view/View). -**DO** use public lifecycle APIs (e.g: via `Robolectric.buildActivity()`) rather than exposing `@VisibleForTesting` methods when testing Android components such as `Activities` and `Services`. Calling those methods directly makes it difficult to refactor the code under test later. +**DO** use public lifecycle APIs (e.g., via [`Robolectric.buildActivity()`](javadoc/latest/org/robolectric/Robolectric.html#buildActivity(java.lang.Class))), rather than exposing `@VisibleForTesting` methods when testing Android components such as `Activity`s and [`Service`](https://developer.android.com/reference/android/app/Service)s. Calling those methods directly makes it difficult to refactor the code under test later. -**DO** limit the number of the threads that are running during each test. Rogue threads often cause test pollution because they are not automatically cleaned up between tests. Oftentimes threads are inadvertently spawned when using third-party libraries (e.g. for networking) or background processing components. One of the main sources of additional threads during tests are `ExecutorService`s that maintain thread pools. If possible, mock dependent components that spawn threads, or use a `DirectExecutor`. If it's necessary to run multiple threads during a test, make sure to explicitly stop all threads and `ExecutorService`s to avoid test pollution. +**DO** limit the number of threads that are running during each test. Rogue threads often cause test pollution because they are not automatically cleaned up between tests. Oftentimes threads are inadvertently spawned when using third-party libraries (e.g., for networking) or background processing components. One of the main sources of additional threads during tests are [`ExecutorService`](https://developer.android.com/reference/kotlin/java/util/concurrent/ExecutorService)s that maintain thread pools. If possible, mock dependent components that spawn threads, or use [`MoreExecutors.directExecutor()`](https://guava.dev/releases/31.1-jre/api/docs/com/google/common/util/concurrent/MoreExecutors.html#directExecutor()). If it's necessary to run multiple threads during a test, make sure to explicitly stop all threads and `ExecutorService`s to avoid test pollution. -**DON'T** mock or spy on Android classes that will be acted on by other Android code (e.g. `Context`, `SharedPreferences`, and many others). Stubbing is very brittle and can lead to breakages on Robolectric or Android Platform upgrades. The small exceptions to this rule are classes with very narrow responsibilities, such as event listeners. +**DON'T** mock or spy on Android classes that will be acted on by other Android code (e.g. [`Context`](https://developer.android.com/reference/android/content/Context), [`SharedPreferences`](https://developer.android.com/reference/android/content/SharedPreferences), and many others). Stubbing is very brittle and can lead to breakages on Robolectric or Android Platform upgrades. The small exceptions to this rule are classes with very narrow responsibilities, such as event listeners. ## Limitations diff --git a/docs/custom-test-runner.md b/docs/custom-test-runner.md index cfdf0010e..54c5f0ee6 100644 --- a/docs/custom-test-runner.md +++ b/docs/custom-test-runner.md @@ -8,14 +8,9 @@ hide: There are several situations where you want to customize Robolectric's test runner to perform some operation before all tests are run, or even before each test method is run. One good example is initializing a dependency injection framework with a different set of dependencies for your test. Fortunately, Robolectric has a way to -hook into the test lifecycle. If you define an Application class in your AndroidManifest.xml, Robolectric will -automatically try and load a test version of your application class first. For example: - -Let's say you've defined a FooApplication in your manifest: - -```xml - -``` +hook into the test lifecycle. If you define an [`Application`](https://developer.android.com/reference/android/app/Application) +class in your `AndroidManifest.xml` file, Robolectric will automatically try and load a test version of your +`Application` class first. ## Hilt