First working version

[jkrems]

Just like testiumjs/testium-driver-wd#1 but for sync. Doing both in parallel to get a feeling for what works with both.

[ghost]

README.md?

[jkrems]

@EndangeredMassa This would be the interface the test framework integrations would be working against, e.g. testium-mocha:

# Preparation
npm install --save-dev testium-driver-sync testium-core

# ~= testium-mocha
initTestium = require 'testium-core'
injectBrowser = (options) ->
  -> # before hook using mocha's promise support
    initTestium(options)
      .then (testium) ->
        driverType = testium.config.get('driverType', 'sync')
        driverType = require("testium-driver-#{driverType}") if typeof driverType == 'string'
        driverType testium
      .then ({@browser}) => # injected browser

describe 'my feature', ->
  before injectBrowser()

  it 'loads a page', ->
    @browser.navigateTo '/'

[jkrems]

@khoomeister I think it's too early for that. This is just the plumbing and the actual interface is in flux. I'll copy the docs as I copy the actual implementations. E.g. all browser.* methods are supposed to be in separate files like in testium. I just hacked in the implementations needed for a first POC test.

[jkrems]

Now with the complete integration test suite from testium.

[jkrems]

Now with eslint (based on airbnb styles) & fixed lint errors.

[jkrems]

Alright! Moved testium-example-app into its own repo so we can reference it from different packages and added a README. Ready for review.

[ghost]

FWIW, this method seems weird and redundant, and makes the code harder to read. The consumers that use it refer to the element and its property value as result[0] and result[1]. You could destructure but I feel like you should just inline.

[jkrems]

Good point. Will switch to inlining. One of the things I should have questioned instead of blindly porting it 1:1.

[ghost]

No blockers

[jkrems]

Added the outstanding things to groupon/testium#171, releasing a 1.0 since the remaining points are all for internals.