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
| 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.
Why do we remove the vm platform here?
There was a problem hiding this comment.
Because we manually include it in the list so we can add "(default)" after it.
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.
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.
| var parser = new ArgParser(allowTrailingOptions: true); | ||
|
|
||
| var allPlatforms = TestPlatform.all.toList(); | ||
| var allPlatforms = TestPlatform.all.toList()..remove(TestPlatform.vm); |
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. |
3 participants
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