Ospec needs a Karma story

[dead-claudia]

Mithril version:

Browser and OS:

Project:

Is this something you're interested in implementing yourself?

Description

ospec needs integrated with Karma so ospec users can use Karma for much easier cross-browser testing.

Why

This is mildly blocking for us moving to Karma internally - the only alternative is literally just moving to another framework. Also, users may appreciate this.

Possible Implementation

Open Questions

[pygy]

Any reason why you want Karma over Selenium? I'm not familiar with the former, I've dabbled with the latter.

[dead-claudia]

Karma has third-party Selenium integration. ;-) Specifically: - Selenium is just a browser automation tool - it competes with Puppeteer. - Karma is a framework-agnostic test runner that runs tests in browsers. It doesn't really make sense to explicitly integrate with Selenium IMHO.

On Tue, Dec 10, 2019 at 20:12 Pierre-Yves Gérardy ***@***.***> wrote: Any reason why you want Karma over Selenium? I'm not familiar with the former, I've dabbled with the latter) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#9?email_source=notifications&email_token=ABCGWBDAHSCOBYACWSNIBNLQYA46FA5CNFSM4JZHAS72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGRQNMY#issuecomment-564332211>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCGWBDAHQ4TJ5S7H6VGW7TQYA46FANCNFSM4JZHAS7Q> .

-- ----- Isiah Meadows [email protected] www.isiahmeadows.com

[pygy]

I say this because the selenium API is rather straightforward (see the krausest benchmarks for an example) and you mentioned elsewhere a 2 second timeout issue with Karma.

Selenium is AFIAK a pretty stable code base. Karma is a Google project that comes with the usual caveats...

We could whip out an ospec-based meta-runner that delegates to selenium, gathers the results and displays them using our machinery. That would take about one page of code...

We can namespace the suites using o.new(browserName).

Edit: disentangling o.run() and o.oncompletion() API-wise would help here.

[dead-claudia]

@pygy I do want to reiterate: Selenium is a browser automation tool first, even though it was designed with use for testing in mind. Karma was created first as a way to run tests in browsers, and was later generalized to support other means of running tests like through Selenium or other WebDriver-compatible APIs, but it's not itself a browser automation tool. Compare these two to Nightwatch.js, which does both.

I say this because the selenium API is rather straightforward (see the krausest benchmarks for an example) and you mentioned elsewhere a 2 second timeout issue with Karma.

That timeout is more browsers being slow, and slower machines (like my main development machine ATM) can sometimes trigger it. It's not usually a Karma issue, but a browser issue.

Selenium is AFIAK a pretty stable code base. Karma is a Google project that comes with the usual caveats...

Karma in my experience has been pretty stable the past few years. I have 3-year-old Karma configs that barely need changed at all, and even the last couple major updates have required just updating plugins and nothing else, not even config changes (aside from taking advantage of new features).

We could whip out an ospec-based meta-runner that delegates to selenium, gathers the results and displays them using our machinery. That would take about one page of code...

That could technically work, but I see no point in reinventing such a complicated wheel personally - it's not as simple as it sounds, and you'd need at least a couple dependencies to do it if you don't want to hand-roll everything. I would accept a patch to add one provided the API is well-documented and it's sufficiently easy to use, but I'm not going to write such a patch myself.

[pygy]

Is this still relevant?