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

Running without webdriver.executeScript() #52

Closed
joeyparrish opened this issue Mar 8, 2024 · 3 comments
Closed

Running without webdriver.executeScript() #52

joeyparrish opened this issue Mar 8, 2024 · 3 comments

Comments

@joeyparrish
Copy link
Contributor

In our test lab, we have partial WebDriver implementations for some consumer electronics devices (TVs, Xbox, etc) that do not support executeScript().

With Karma, we didn't need executeScript(). Communication from the jasmine environment back to the runner was done through a WebSocket.

I would like to explore removing the getBatch() function in lib/runner.js, which is based on executeScript(). This will allow us to use jasmine-browser-runner on all our lab devices. I believe we could open a web socket back to jasmine-browser-runner's express-based web server for reporting, instead of dumping batches of events with executeScript().

@sgravrock
Copy link
Member

I'm not opposed, particularly since the executeScript based mechanism is a possible cause of flakiness in Circle CI. (And was a massive pain point back when we had to support IE, but fortunately that's not a concern any more.) I'd be willing to merge a PR that switched to WebSockets and release it after some soak time if it proved to be at least as stable as what we've got now.

There is one major caveat though: None of the platforms you mention are supported, and that's not going to change. It can't change, because I don't have any way to test Jasmine on those devices. So there's always a possibility that a future change to jasmine-core or jasmine-browser-runner could break compatibility with those environments, and it would only be restored if you submitted a PR to fix it. But I imagine you'd have that problem no matter what testing tools you choose.

@joeyparrish
Copy link
Contributor Author

That makes sense. We're already in that boat in general with Karma+Jasmine, and it doesn't concern me. I wouldn't require you to officially support any of our weird platforms. I think in general, package-lock.json will prevent us from getting broken by surprise, and if we found issues during an upgrade, we would be more than willing to contribute fixes.

@joeyparrish
Copy link
Contributor Author

This might not be the best successor to Karma for us, based on conversation in #51. So we will drop this issue and continue the search elsewhere. Thanks for your time!

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