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

Allow filtering of specs when tests being run #865

Closed
keirlawson opened this issue May 26, 2015 · 5 comments
Closed

Allow filtering of specs when tests being run #865

keirlawson opened this issue May 26, 2015 · 5 comments

Comments

@keirlawson
Copy link

Currently, by using a custom boot.js file a specFilter can be used to select which tests should be run. The problem is that this filtering happens when tests are being first registered with Jasmine, rather than when they are being run. This means that creating a single page interactive test runner is impossible as it is not possible to filter tests based on user input without refreshing the page.

@slackersoft
Copy link
Member

The way to specify a spec (or specs) to run as you are executing the suite is to pass an array of spec and suite ids to the execute function itself. This would mean that your test runner would have to know the ids for all of the spec and/or suite objects that are constructed and associate those with whatever UI you have to let the user pick specs.

Does this solve your problem?

@keirlawson
Copy link
Author

Looks like it might, is there a public API which can be used to retrieve spec/suite IDs? I didn't find information in the documentation about that parameter for execute, did I miss it or has it not been documented?

@slackersoft
Copy link
Member

Once all the specs have been loaded you should be able to call the topSuite() function on your jasmine Env (jasmine.getEnv().topSuite() if you're not managing the env some other way already). You should be able to then walk down that tree to get all of the Spec objects to retrieve their ids.

The execute function on Env isn't well documented because it is primarily for internal use, and this kind of use case is a bit of an advanced feature.

@keirlawson
Copy link
Author

Would you accept a PR to document the execute param? It would be useful for my use case but I'm not keen on using undocumented features that might be subject to breaking changes within minor versions.

@slackersoft
Copy link
Member

I'd be happy to have some better documentation for the execute function.

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

2 participants