Gitiles
Code Review Sign In
LeafOS / LeafOS-Project / android_frameworks_base / ee5b9cb7dac05ccd8a5cf1ad1b36cde4d5653b29 / . / ravenwood
tree: bc9684f494c8c3e55e5394775228769b414fa784 [path history] [tgz]
  1. annotations-src/
  2. bivalenttest/
  3. coretest/
  4. junit-impl-src/
  5. junit-src/
  6. junit-stub-src/
  7. minimum-test/
  8. mockito/
  9. runtime-helper-src/
  10. services-test/
  11. Android.bp
  12. api-maintainers.md
  13. bulk_enable.py
  14. fix_test_runner.py
  15. framework-minus-apex-ravenwood-policies.txt
  16. list-ravenwood-tests.sh
  17. OWNERS
  18. ravenwood-annotation-allowed-classes.txt
  19. ravenwood-services-jarjar-rules.txt
  20. ravenwood-standard-options.txt
  21. README.md
  22. run-ravenwood-tests.sh
  23. services.core-ravenwood-policies.txt
  24. test-authors.md
  25. TEST_MAPPING
ravenwood/README.md

Ravenwood

Ravenwood is an officially-supported lightweight unit testing environment for Android platform code that runs on the host.

Ravenwood’s focus on Android platform use-cases, improved maintainability, and device consistency distinguishes it from Robolectric, which remains a popular choice for app testing.

Background

Executing tests on a typical Android device has substantial overhead, such as flashing the build, waiting for the boot to complete, and retrying tests that fail due to general flakiness.

In contrast, defining a lightweight unit testing environment mitigates these issues by running directly from build artifacts (no flashing required), runs immediately (no booting required), and runs in an isolated environment (less flakiness).

Guiding principles

Here’s a summary of the guiding principles for Ravenwood, aimed at addressing Robolectric design concerns and better supporting Android platform developers:

  • API support for Ravenwood is opt-in. Teams that own APIs decide exactly what, and how, they support their API functionality being available to tests. When an API hasn’t opted-in, the API signatures remain available for tests to compile against and/or mock, but they throw when called under a Ravenwood environment.
    • Contrasted with Robolectric which attempts to run API implementations as-is, causing maintenance pains as teams maintain or redesign their API internals.
  • API support and customizations for Ravenwood appear directly inline with relevant code. This improves maintenance of APIs by providing awareness of what code runs under Ravenwood, including the ability to replace code at a per-method level when Ravenwood-specific customization is needed.
    • Contrasted with Robolectric which maintains customized behavior in separate “Shadow” classes that are difficult for maintainers to be aware of.
  • APIs supported under Ravenwood are tested to remain consistent with physical devices. As teams progressively opt-in supporting APIs under Ravenwood, we’re requiring they bring along “bivalent” tests (such as the relevant CTS) to validate that Ravenwood behaves just like a physical device.
    • Contrasted with Robolectric, which has limited (and forked) testing of their environment, increasing their risk of accidental divergence over time and misleading “passing” signals.
  • Ravenwood aims to support more “real” code. As API owners progressively opt-in their code, they have the freedom to provide either a limited “fake” that is a faithful emulation of how a device behaves, or they can bring more “real” code that runs on physical devices.
    • Contrasted with Robolectric, where support for “real” code ends at the app process boundary, such as a call into system_server.

More details