Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Support pluggable launchers #99

Open
nex3 opened this issue May 4, 2015 · 0 comments
Open

Support pluggable launchers #99

nex3 opened this issue May 4, 2015 · 0 comments
Labels
plugin API status-blocked Blocked from making progress by another (referenced) issue type-enhancement A request for a change that isn't a bug

Comments

@nex3
Copy link
Member

nex3 commented May 4, 2015

It should be possible for developers to create custom launchers for browsers that users can then include, like other plugins. These launchers would presumably have a similar API to the existing Browser interface: a way to create an instance that's pointing to a given URL, monitor that instance's uptime, and close it if necessary.

This is blocked on #48.
@nex3 nex3 added type-enhancement A request for a change that isn't a bug status-blocked Blocked from making progress by another (referenced) issue labels May 4, 2015
@nex3 nex3 added this to the 1.0.0 milestone May 4, 2015
@nex3 nex3 mentioned this issue May 7, 2015
Closed
@nex3 nex3 mentioned this issue May 26, 2015
Closed
@nex3 nex3 mentioned this issue Jun 23, 2015
Closed
@nex3 nex3 mentioned this issue Jul 9, 2015
Closed
This was referenced Aug 17, 2015
Closed
Open
Closed
@nex3 nex3 mentioned this issue Nov 16, 2015
Closed
@nex3 nex3 added the plugin API label Jun 6, 2017
@nex3 nex3 modified the milestone: 1.0.0 Jun 6, 2017
nex3 added a commit that referenced this issue Oct 3, 2017
@nex3
Store test platforms as strings in Configuration
bbba43d 
This will make it easier to define custom test platforms (both via #391
and #99) in the future. Because those platforms will be loaded based on
the configuration, requiring knowledge of them to parse the user's
platform arguments would produce an unresolvable circular dependency.
@nex3 nex3 mentioned this issue Oct 3, 2017
Merged
nex3 added a commit that referenced this issue Oct 3, 2017
@nex3
Store test platforms as strings in Configuration (#692)
bfd24ca 
This will make it easier to define custom test platforms (both via #391
and #99) in the future. Because those platforms will be loaded based on
the configuration, requiring knowledge of them to parse the user's
platform arguments would produce an unresolvable circular dependency.
nex3 added a commit that referenced this issue Oct 3, 2017
@nex3
Don't use TestPlatform.all in PlatformSelector
4a4174e 
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
@nex3 nex3 mentioned this issue Oct 3, 2017
Merged
nex3 added a commit that referenced this issue Oct 3, 2017
@nex3
Don't use TestPlatform.all in PlatformSelector (#693)
7f7d218 
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
nex3 added a commit that referenced this issue Oct 3, 2017
@nex3
Send test platforms to the remote listener
11ea99f 
This ensures that the remote listener has access to any platforms that
are dynamically loaded in the test runner, so they can be used in
platform selectors.

See #99
See #391
@nex3 nex3 mentioned this issue Oct 3, 2017
Merged
nex3 added a commit that referenced this issue Oct 4, 2017
@nex3
Send test platforms to the remote listener (#694)
0a3f688 
This ensures that the remote listener has access to any platforms that
are dynamically loaded in the test runner, so they can be used in
platform selectors.

See #99
See #391
@nex3 nex3 mentioned this issue Oct 5, 2017
Closed
@nex3 nex3 mentioned this issue Oct 19, 2017
Merged
nex3 added a commit that referenced this issue Oct 19, 2017
@nex3
Merge pull request #706 from dart-lang/feature.flexible-test-platforms
47debed 
Add the ability to define and override test platforms

See #99
Closes #391
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
plugin API status-blocked Blocked from making progress by another (referenced) issue type-enhancement A request for a change that isn't a bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@nex3