Workspace support for dart test?

[jakemac53]

We could consider running all tests in the workspace, if running dart test from the workspace root.

Some high level thoughts:

• We might want to guard this behind a flag, --recursive or similar. The workspace root also might have its own tests and otherwise we can't tell the difference between user intents.
• Not all packages in a repo have to be a part of a workspace, so people might get confused (removing a package from the workspace makes dart test from the root not run its tests).
  • We could mitigate this by explicitly listing the packages whose tests we are running.
• There might be other edge cases based on other logic that assumes the current working directory is the package. We could change the working dir before running tests in each package, but that might be too magical.

Maybe this should be the job of a different tool - like pub 🤣 (but more realistically the dart tool).

[matanlurey]

Some thoughts:

• We might want to guard this behind a flag, --recursive or similar. The workspace root also might have its own tests

Seems reasonable to me. This is a command probably more likely used either on CI, or pre-CI, not edit-refresh cycle.

Not all packages in a repo have to be a part of a workspace

Less concerned, particularly if we do dart test --recursive (or dart test --workspace?)

• There might be other edge cases based on other logic that assumes the current working directory is the package

This is definitely true.

I find in my own tests the inability to rely on Platform.currentScript (?) with pkg/test makes it very hard to read relative files on disk, and I'm guessing many many apps (my own included) make assumptions around CWD. If pkg/test exposed some sort of environment variable or -D that could be used for this purpose at least there is a migration path?

[jakemac53]

Less concerned, particularly if we do dart test --recursive (or dart test --workspace?)

I like --workspace that is a lot more clear 👍

[jakemac53]

I find in my own tests the inability to rely on Platform.currentScript (?) with pkg/test makes it very hard to read relative files on disk, and I'm guessing many many apps (my own included) make assumptions around CWD. If pkg/test exposed some sort of environment variable or -D that could be used for this purpose at least there is a migration path?

I think a general purpose API of some sort is best here, it has been discussed for quite some time without resolution though #110. A -D variable wouldn't work when running tests in an isolate, because while an environment is allowed to be passed, it is not supported. It would also prevent us from sharing compilation across tests.

[matanlurey]

Thanks, I will leave a comment on that issue.