Get Browser Information with Intern

By  on  

You know how you can't remember something your spouse feels is really important but you can remember every funny line from that movie you saw when you were 17?  That's how I feel after months of writing selenium tests using the Intern framework -- I've forgotten lots of important front-end stuff but I've uncovered loads of selenium issues and techniques to hack around them.

I initially wrote my tests using Firefox as the test browser.  Then I opened up my testing to Chrome and needed to adjust a whole bunch of stuff because Chrome doesn't reliably do things like Firefox, like element `click` vs. `enter` key press.  And don't ask me about concurrency issues.  Then today I had the bright idea of adding Safari to the mix.  In a word....f*ck.  A whole new world of issues cropped up.

One issue that Selenium + Safari has (one of dozens) is history / URL issues.  After doing loads of research and implementing every hack I could think of, I had this moment:

Fuck It

If there's a Selenium issue in a given browser that makes it impossible for a test to complete properly, there's no point in fighting it -- this case calls for simply passing the test instead of dealing with the annoyance of seeing a failure due to Selenium error.   But how do you get browser information within a test?


// From within a test function
console.log(this.remote.session.capabilities);

{
  'webdriver.remote.sessionid': 'f4dffffc-8d40-4e21-a862-459109ffabfc',
  browserName: 'safari',
  takesScreenshot: true,
  javascriptEnabled: true,
  version: '8.0.8',
  cssSelectorsEnabled: true,
  platform: 'MAC',
  secureSsl: true,
  remoteFiles: true,
  nativeEvents: false,
  rotatable: false,
  locationContextEnabled: false,
  webStorageEnabled: false,
  applicationCacheEnabled: false,
  supportsNavigationDataUris: true,
  supportsCssTransforms: true,
  supportsExecuteAsync: true,
  mouseEnabled: true,
  touchEnabled: false,
  dynamicViewport: true,
  shortcutKey: '',
  brokenDeleteCookie: false,
  brokenExecuteElementReturn: false,
  brokenExecuteUndefinedReturn: false,
  brokenElementDisplayedOpacity: false,
  brokenElementDisplayedOffscreen: false,
  brokenSubmitElement: true,
  brokenWindowSwitch: true,
  brokenDoubleClick: false,
  brokenCssTransformedSize: true,
  fixedLogTypes: false,
  brokenHtmlTagName: false,
  brokenNullGetSpecAttribute: false,
  brokenNavigation: true,
  brokenMouseEvents: true,
  brokenWindowPosition: true,
  brokenSendKeys: true,
  brokenCookies: true 
}

The session object on the remote provides information about the browser session, including the name (most important) as well as fixes provided by Intern.

In an ideal world you can write all of your Selenium tests in one format and it works within each browser....but we don't live in an ideal world, the same way we need browser hacks within our client side JavaScript.  Being able to get browser name and other information within a test, however, is just another super useful bit of information exposed by Intern!

Recent Features

Incredible Demos

  • By
    CSS Kwicks

    One of the effects that made me excited about client side and JavaScript was the Kwicks effect.  Take a list of items and react to them accordingly when hovered.  Simple, sweet.  The effect was originally created with JavaScript but come five years later, our...

  • By
    Redacted Font

    Back when I created client websites, one of the many things that frustrated me was the initial design handoff.  It would always go like this: Work hard to incorporate client's ideas, dream up awesome design. Create said design, using Lorem Ipsum text Send initial design concept to the client...

Discussion

  1. Pablo

    Nice to hear that I’m not the only one that feels that way at times. Make sure you get back to delivering awesome content in due time though! :D

Wrap your code in <pre class="{language}"></pre> tags, link to a GitHub gist, JSFiddle fiddle, or CodePen pen to embed!