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.

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

CP-3228 Use test runner when collecting coverage #200

Closed
greglittlefield-wf opened this issue Jan 4, 2017 · 5 comments
Closed

CP-3228 Use test runner when collecting coverage #200

greglittlefield-wf opened this issue Jan 4, 2017 · 5 comments

Comments

@greglittlefield-wf
Copy link
Contributor

When running tests coverage, platform selectors don't work as expected since the test runner isn't being used.

E.g., tests with testOn: !content-shell still run during coverage.

Now that dart-lang/test#36 isn't blocked, this should be possible.

@rmconsole3-wf rmconsole3-wf changed the title Use test runner when collecting coverage CP-3228 Use test runner when collecting coverage Jan 4, 2017
@evanweible-wf
Copy link
Contributor

Awesome! Thanks for the heads up @greglittlefield-wf. I'll try to roll this in to V2 with the rewrite of the coverage task.

@greglittlefield-wf
Copy link
Contributor Author

This also prevents us from using test tags, which seem to be the most promising way so far to run certain tests conditionally based on whether you're in the DDC: dart-lang/test#652

@maxwellpeterson-wf
Copy link
Member

@greglittlefield-wf could you clarify this part: Now that dart-lang/test#36 isn't blocked, this should be possible.

@evanweible-wf

@greglittlefield-wf
Copy link
Contributor Author

greglittlefield-wf commented Nov 21, 2017

@maxwellpeterson-wf I think when I created this issue, it seemed possible to be able to hook coverage and the test runner together with some observatory/isolate magic.

However, based on this comment in that issue I linked: dart-lang/test#36 (comment)

I agree that the best approach here is for test to be involved in coverage collecting—that's the best way to ensure a smooth user interface and to avoid dependencies on test's internal structure, which is not a guaranteed stable interface.

it seems like it's probably best to rely on changes in test to facilitate coverage collection.

@evanweible-wf
Copy link
Contributor

Coverage collection through the test runner is in progress, so this should no longer need to be a ddev concern.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants