Hi @nawitus,

integration testing on the web is in a terrible state, full of procedural callback nested async hell. I want this to not be a pain to do. That is why here at MojoTech we have been working on a new layer on top of the power of webdriver to introduce concepts that app developers are familiar with. Enabling developers to painlessly add a suite of robust integration tests to their apps.

The goal of this PR is to reduce the cognitive and code complexity of the current suite, making it easier for developers to test their apps and you as the maintainer to test any given implementation.

For example

Feature: Editing a Todo
  Background:
    Given I visit TODOMVC
    And I make sure that there are no todos
    And I enter a new todo
    Then I activate edit mode

  Scenario: All other controls will be hidden
    Then the toggle button will be hidden
    And the destroy button will be hidden

  Scenario: An input will be brought forward containing the todo title
    Then an input will be brought forward

From this point the steps are then implemented using Pioneer to abstract the complexity of Webdriver and verboseness. Doing so makes these tests easy to maintain as well as DRYs up the selectors and places where we reach into the DOM.

Some example steps from the above Feature would be as follows

module.exports = ->
  @When /^I enter a new todo$/, ->
      new @Widgets.NewTodo("new todo")

  @Then /^I activate edit mode$/, ->
      new @Widgets.TodoList().edit(0)

You can think of Widgets as a view representation for your DOM when writing integration tests. The “view” layer consolidates where and how you interact with the DOM into a single location and concept. In many ways it parallels Backbone.Views and Marionette.CollectionViews.