Currently, inside the Dart SDK we use package:test_runner. Outside the Dart SDK, people use package:test.

Some of the features align:

• They can run all files in a directory that end with test.dart.

Some features don't align:

• Skips: package:test has annotations or named arguments, the Dart SDK status files.
• Expectations: package:matcher vs package:expect

Some SDK testing requirements are built in to package:test_runner and might not make sense outside the Dart SDK:

• multi tests
• comment expectations for // [cfe] and // [analyzer]
• bots/configurations
• results database

(Some of these things might actually be useful outside the Dart SDK. Multitests? Configurations to express cross-compilation once we start supporting that in standalone Dart. A serializable output for test results?)

Having these different solutions creates friction if packages are both used inside the Dart SDK and outside the Dart SDK. (For example: packages available outside the Dart SDK for users, or shared code between Dart and Flutter.)

Maybe we could reduce tech debt by trying to converge testing solutions.

It is not clear to me what the desired end state of a convergence should be, but some possibilities:

• Using package:test syntax for skips instead of status files.
• Dropping package:expect and starting to use package:matcher.
• Building package:test_runner on top of package:test with our SDK-specific requirements? (But not reinventing the wheel for shared things.)

It's likely that trying to converge testing is a lot of effort, so we might not want to prio this. But I wanted a tracking bug.

@johnmccutchan Do we have a tracking issue on the Flutter side for converging testing frameworks?

N.b. Feel free to edit this issue to add bullet points to the list above.