fippo
commented
1 year ago I've run those tests for ~2 weeks now and they were surprisingly reliable (unlike the samples tests...) Adding Safari to the mix is possible (but that has a minute multiplier of 10) too but I'd rather run the basic case that we want to replace apprtc first for a month or two before getting more ambitious.
One of the tricky things is that chromedriver normally has a version check which allow it to operate +- 1 release of the chrome version. This broke when Chrome Unstable went to M108 and required adding the disable-build-check flag.
It might actually be useful to extend the chromedriver flag to specify a range of 2 as an argument instead of completly disabling the check
Description
adds interoperability tests between Chrome unstable and Firefox Nightly. These tests are designed to run nightly as github actions. Github provides a "free" budget of 2000 minutes per month. In the current configuration with four tests (a matrix of Chrome/Firefox) that each take around a minute the nightly runs have a "cost" of 120 minutes per month.
The tests do not rely on a signaling server, instead use the mocha-based test that is controlling the individual selenium webdriver instances to act as a signaling channel which exchanges offers and answers with candidates. This pattern is described in the testbed repository https://github.com/fippo/testbed from 2016, this is a "more modern" take on the same subject.
To run the tests locally,
Running them with Chrome/Firefox unstable requires Linux for the integration with travis-multirunner and setting the
Purpose Getting rid of the dependency on apprtc in tests while keeping a minimum level of interoperability tests