Files
sdk/pkg/dynamic_modules/test/data
Lasse R.H. Nielsen f8086c81ae Collect all test-related files in package:expect.
Collects files from `package:async_helper` and `tests/language`
that are generally useful, so that all test-related helpers are
in `package:expect`.

Moves the two libraries from `package:async_helper` into `package:expect`,
and the `tests/language/static_type_helper.dart` file too.

Deprecates `async_minitest.dart`, to follow `minitest.dart`,
expecting the Flutter use of it to have been fixed to not break
on deprecation (I believe Flutter no longer breaks builds on deprecations at all).

Patch 1 is the actual change.
Patch 2+4+8 is changing all existing references to the files.
Patch 6 ignores deprecation in files still using `async_minitest.dart`.

3+5+7+9 are updating this text to make the numbers match.
Then it's just test-expectations and small tweaks from there.

Change-Id: I1b665135b5fef9b9a0c3b340ffe9daf874d0174c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373120
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Devon Carew <devoncarew@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
2024-10-11 16:53:52 +00:00
..

Tests for Dart dynamic modules

This folder contains tests for an experiment of implementing dynamic modules in Dart. All tests are written in the style of the language end-to-end tests.

Folder structure

Each folder consists of a single test scenario. You'll find 4 kinds of files:

  • main.dart: the host application that will later load dynamic modules. This will be the core driver of the test.

  • shared/: folder containing multiple libraries with code that can be used by both the host application and dynamic modules.

  • modules/: folder containing code private to dynamic modules. It includes libraries with common code as well as an entrypoint file per dynamic module. Entrypoint files are named entryN.dart and must define an exported dynamic module entrypoint. Note: semantics limit that two dynamic modules can't share code unless they are compiled in a chained fashion, currently the test harness focuses on compiling modules in isolation and ensuring conflicts don't arise.

  • dynamic_interface.yaml: a contract specifying what parts of the host application and libraries in shared/ are visible to dynamic modules.

Execution

We've build a test framework that frontloads compilation, so that execution of the test can be streamlined. This means that:

  • The host app will be compiled first, using dynamic_interface.yaml as a specification for AOT compilers.

  • Each and every dynamic module entrypoint in modules/ will be compiled to create a dynamic module artifact.

  • Finally an execution environment will be launched that will in turn load each dynamic module as prompted by the test logic.

Commands to drive the loading and execution of each dynamic module are controlled by a helper library in ../common/testing.dart, which uses the Dart SDK API and abstracts away differences between platforms.

Example

Refer to update_top_level. This is one of the simplest tests that illustrates the utilities and concepts in this framework.