by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 01:02
    jason0x43 labeled #1173
  • 01:02
    jason0x43 unlabeled #1173
  • 01:01
    jason0x43 closed #1174
  • 01:01
    jason0x43 commented #1174
  • 01:00

    jason0x43 on 4.8

    fix: add missing dot for tsx fi… (compare)

  • 01:00

    jason0x43 on master

    fix(core): add missing dot for … (compare)

  • 00:50

    jason0x43 on master

    add missing dot for tsx file ex… (compare)

  • 00:50
    jason0x43 closed #1175
  • Sep 23 07:37
    lxghtless edited #1174
  • Sep 23 07:35
    jsf-clabot commented #1175
  • Sep 23 07:35
    jsf-clabot commented #1175
  • Sep 23 07:35
    lxghtless opened #1175
  • Sep 23 07:31
    github-actions[bot] labeled #1174
  • Sep 23 07:31
    lxghtless opened #1174
  • Sep 20 19:16
    github-actions[bot] labeled #1173
  • Sep 20 19:16
    tillyboy opened #1173
  • Sep 08 15:19
    jsf-clabot commented #84
  • Sep 08 15:19
    dependabot[bot] synchronize #84
  • Sep 08 15:19

    dependabot[bot] on npm_and_yarn

    Bump handlebars from 4.1.0 to 4… (compare)

  • Sep 08 15:19
    dependabot[bot] edited #84
Dylan Staley
@dstaley
So intern always downloads the latest version of the driver? Would it make sense to provide an option to download the driver that matches the installed version of Chrome?
Because I can pin to v81 to get tests passing now, but in a few days when the environment updates to v83 I'm gonna have the same issue.
I guess I could, in CI, interpolate the chrome version into the config?
Jason Cheatham
@jason0x43
Intern does download the latest version as that's the most common use case. Detecting the local version would be useful, but tricky, particularly if the browser being used was in a non-standard location.
Being able to use environment variables in the config would handle the GHA case (and would be generally useful). You can already use an INTERN_ARGS environment variable to pass command line options, but it's not very ergonomic for something like this.
Dylan Staley
@dstaley
So the best solution for right now would be updating the config with the value from the CHROMEDRIVER variable?
Jason Cheatham
@jason0x43
Unfortunately, there isn't a way to configure a path to a local webdriver executable, so the best solution for the moment is to pin the version in the config. Depending on the format of their CHROMEWEBDRIVER variable, you might be able to extract the local version from that and use it to set the webdriver version.
Dylan Staley
@dstaley
Yeah that's what I'll try. I'll report the format in the issue
Jason Cheatham
@jason0x43
:thumbsup:
Dylan Staley
@dstaley
Wait, it looks like GHA is installing ChromeDriver in addition to Chrome. Can intern pick up on that since it's in the PATH?
Dylan Staley
@dstaley
Ah okay nevermind, looks like the issue encompasses updating digdug to accept a path to an executable
Dylan Staley
@dstaley
When pinning a webdriver version, should tunnelOptions go at the root of the config?
Jason Cheatham
@jason0x43
Yes.
{
  "tunnelOptions": {
    "drivers": [ { "name": "chrome", "version": "81.xxx" } ]
  }
}
MarvDann
@MarvDann
Hi Jason, what is the recommended way to mock api requests in intern 3? I have tried using nock but was unable to import it as a module after using bower to install it as a package alongside dojo in /src folder
Scott Davis
@stdavis
image.png
So I have unit tests running in the browser. How do I get those to run in a headless browser on my CI server?
Jason Cheatham
@jason0x43
@MarvDann If you're using dojo for requests, you can mock the request handling during tests. If you're using something else, you could try Sinon, which provides facilities for mocking XHR requests.
Jason Cheatham
@jason0x43
@stdavis In a CI system, you'd run Intern from the command line, and use the Selenium tunnel (assuming the browser is on your CI system) to load and manage the browser. In your Intern config, you'd setup an environment for headless chrome (see https://theintern.io/docs.html#Intern/4/docs/docs%2Fhow_to.md/run-tests-with-headless-chrome). Note that your CI system would need Java (headless Java is fine) to run Selenium. If Java isn't an option, you can also interact with chromedriver directly, but it's a bit more work (better support for direct interaction with web drivers is in the works).
1 reply
Dylan Staley
@dstaley
Is Firefox on GitHub Actions really flaky? I feel like every third run fails with Timeout: [POST http://localhost:4444/wd/hub/session / {"desiredCapabilities":{"name":"intern","idle-timeout":60,"browserName":"firefox","moz:firefoxOptions":{"args":["-headless"],"browser":"firefox"}}] connection refused
rhpijnacker
@rhpijnacker
Since upgrading from Intern 3 to Intern 4 we have a number of files that have (much) lower code coverage.
I've been able to chase this down to test cases that use a (dojo) context require with a map to reroute dependencies to mock files. After the test case is finished, we clean up the loaded module (using require.undef) to force-load it (without mocked dependencies) the next time it is needed.
It seems that reloading a module with Intern 4 resets the coverage built up so far, whereas with Intern 3 this wasn't the case.
Any thoughts on how to work around this? Do we even consider this a bug?
Jason Cheatham
@jason0x43
I'd call that a bug. At least, I would expect coverage to be cumulative over the course of a test session.
rhpijnacker
@rhpijnacker
Ok, filed an issue with repro
Jason Cheatham
@jason0x43
Awesome, thanks
sKudum
@sKudum
Hi Team, any one ran Jasmine typescripts on saucelab?
John Lindal
@jafl
Is there an easy way to get the parent of an Element?
Jason Cheatham
@jason0x43
There's not an API function for that, but you should be able to get it with an execute block:
const element = remote.findByCssSelector('.some-element');
const parentNode = await remote.execute(function (node) {
  return node.parentNode;
}, [element]);
John Lindal
@jafl
Thanks!
tillyboy
@tillyboy
Sry for the most noob question of the day but I am trying to set up a workflow (learning about Web Development) and it seems I can't intern to test against a browser. For Chrome it either says that the version is wrong, or that it cannot download 85.0 from the specified URL. Version 85.0 is however available from the official google API. With Firefox I get a suide error occured. Can anyone tell me how to set this up?
Jason Cheatham
@jason0x43
Hi! Hmmm...it looks like the default webdriver versions used by Intern had slipped a bit. If you're using the most recent Intern, I pushed an updated list of webdriver versions that Intern should see the next time you run it. If you want to specify a version, you can use the tunnelOptions property, like:
"tunnelOptions":: {
  "drivers": [ { name: "chrome", "version": "85.0.4183.87" } ]
}
tillyboy
@tillyboy
Ok, so now I get Chrome to start and do some random stuff, which seems good to me. However I get
Error: Unable to load /tests/box.spec.ts
at HTMLScriptElement.<anonymous> @ node_modules/intern/browser/remote.js:168:45068
No unit test coverage for chrome on linux
Jason Cheatham
@jason0x43
TypeScript isn't (yet) supported in browsers, so you'll need to build your tests first. For example, using webpack, create a bundle that includes all of your unit tests, and then use that bundle in the browser. You can provide separate suites lists for Node and Browsers to keep using the TS suites in Node:
// intern.json
{
  "node": {
    "suites": "tests/**/*.ts"
  },
  "browser": {
    "suites": "build/tests.js"
  }
}