Question: Why not include the test package in the SDK by default?

[grab-a-byte]

I know this isn't an issue but I noticed that writing tests in dart requires the use of the package manager. This could hinder writing tests for scripts that people may wish to write in dart.

Given you can import files locally without issue in dart, I was curious as to why the SDK by default doesn't include the test package as this could allow for a 'test file' and 'script file' kind of workflow both for a simpler introduction to the language and for an ease in for new developers (both to dart and to testing)

Thanks for all the hard work on dart, it is my go-to language for a lot of scripts I write and the tooling around it is great. Please keep up the fantastic work the team is doing. Also I find your open communications through the dart blog to be fantastic :)

[FMorschel]

Maybe at the least we could consider adding test by default in dev dependencies for all create commands?

CC @bwilkerson

[bwilkerson]

@lrhn For the dart: libraries question.

@devoncarew Who's the best contact person for the create commands?

[lrhn]

There are two ways one could include a test framework in the SDK:

• including package:test in the SDK.
• making it instead a dart:test platform library.

Both have issues.

The test package is versioned independently of the SDK. If we included one version with the SDK, would everybody then be forced to use that version, or would it just save one download if all the packages of a project happen to allow solving package:test to that version?

Forcing a single version, aka. package pinning, is a very problematic thing to do. And it's aggravated by a package having multiple dependencies itself, and package:test has many.

Not forcing people to use the shipped version, but making it implicitly available, as package:test, to all code that does not have a package configuration ... could work. Today, if your code has no package configuration, you cannot resolve any package: URIs. This would make it so that there is always at least one version of package:test available, and if code has no package configuration, then package:test resolves to that one version.

And then there is the option of making it dart:test. That makes it impossible to version, and basically impossible to change, the test API. We're currently trying to do that (see package:checks). It's much easier to work with code that is not a platform library. Anything that can not be a platform library, should not be one.

All of these things have an extra (very significant) complication: Dependencies.
A package which depends on the test package has the following transitive dependencies:

• _fe_analyzer_shared
• analyzer
• args
• async
• boolean_selector
• cli_config
• collection
• convert
• coverage
• crypto
• file
• frontend_server_client
• glob
• http_multi_server
• http_parser
• io
• js
• logging
• matcher
• meta
• mime
• node_preamble
• package_config
• path
• pool
• pub_semver
• shelf
• shelf_packages_handler
• shelf_static
• shelf_web_socket
• source_map_stack_trace
• source_maps
• source_span
• stack_trace
• stream_channel
• string_scanner
• term_glyph
• test
• test_api
• test_core
• typed_data
• vm_service
• watcher
• web
• web_socket
• web_socket_channel
• webkit_inspection_protocol
• yaml

Including one package in the SDK might seem reasonable, but not 48 packages.

So, what can we do instead?

We could try to allow code that does't have a package configuration to still depend on package:test.

If it does so, a pub get is run automatically when needed (if it hasn't been already for the current SDK version) to get a specific version of package:test and its dependencies, basically a hard-coded pubspec.lock, creating a single SDK-specific package configuration.
Then the code is run with that default package configuration, plus errors if code with no package config actually depends on any package other than test.

I think that's a more likely approach than including a test package in the SDK.
(I don't know if we want this, but I definitely do not want pinned packages or dart:test.)

[lrhn]

We do add test as a dev-dependency is almost all templates.
I think the only dart create template which doesn't include test directly is web. I don't know what it does for testing.