-
Notifications
You must be signed in to change notification settings - Fork 218
Don't use TestPlatform.all in PlatformSelector #693
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't use TestPlatform.all in PlatformSelector #693
Conversation
We want users to be able to dynamically define new platforms, which means we need infrastructure in place for piping those platforms to places that previously assumed TestPlatform.all was a full list of available platforms. PlatformSelector is the trickiest example, since it's parsed in a number of different places and needs to provide useful feedback to users when they use an undefined platform. This splits parsing and platform validation into two separate steps. Validation will be done immediately after parsing when the selectors come from top-level annotations or parameters passed to test() or group(), but selectors defined in configuration files are now parsed only after all configuration is parsed. This will allow new platforms to be defined *and* referenced in configuration files. See #99 See #391
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have an example of how one would define a new platform?
import 'reporters.dart'; | ||
import 'values.dart'; | ||
|
||
/// The parser used to parse the command-line arguments. | ||
final ArgParser _parser = (() { | ||
var parser = new ArgParser(allowTrailingOptions: true); | ||
|
||
var allPlatforms = TestPlatform.all.toList(); | ||
var allPlatforms = TestPlatform.all.toList()..remove(TestPlatform.vm); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we remove the vm platform here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because we manually include it in the list so we can add "(default)" after it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh I see.
Actually defining a platform isn't supported yet; this is just laying the groundwork. But my plan is laid out in #391. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noted. We'll have to be careful when we pull this into Google3. As long as this: https://github.com/dart-lang/test/blob/master/lib/src/backend/test_platform.dart#L111 still works we should be good.
import 'reporters.dart'; | ||
import 'values.dart'; | ||
|
||
/// The parser used to parse the command-line arguments. | ||
final ArgParser _parser = (() { | ||
var parser = new ArgParser(allowTrailingOptions: true); | ||
|
||
var allPlatforms = TestPlatform.all.toList(); | ||
var allPlatforms = TestPlatform.all.toList()..remove(TestPlatform.vm); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh I see.
As this CL stands, that should continue to work, but I'm hoping to refactor it a bit to make it more similar to other plugin API stuff we expose. |
We want users to be able to dynamically define new platforms, which
means we need infrastructure in place for piping those platforms to
places that previously assumed TestPlatform.all was a full list of
available platforms. PlatformSelector is the trickiest example, since
it's parsed in a number of different places and needs to provide useful
feedback to users when they use an undefined platform.
This splits parsing and platform validation into two separate steps.
Validation will be done immediately after parsing when the selectors
come from top-level annotations or parameters passed to test() or
group(), but selectors defined in configuration files are now parsed
only after all configuration is parsed. This will allow new platforms to
be defined and referenced in configuration files.
See #99
See #391