In other words, a widget's "root" css selector should only be used to acquire a reference to an element. Once the reference is obtained, operations like finding its children should use find() on the original webElement rather than trying to construct an unique css selector for each child. Widgets should be constructable using a previously existing WebElement, which would mean the CSS root selector was never used at all. Child widgets in the case of List would then simply inherit WebElements that were optained from their parent List Widget's WebElement.find().

Currently the browser closes and opens per test set (to remove state)
https://github.com/mojotech/dill.js/blob/master/src/support/index.coffee#L70

However this should be something that a user can disable.

Currently the only way that you can create a new widget and find its sub elements is for that widget to have a selector. There are cases where you want to have an raw webElement and want to interact with it via the DIll.js API.

This API change should resolve multiple open bugs

fixes #20
fixes #14
fixes #8

Currently you can

• .extend <= sync
• passing in options to the class <= sync
• .find <= resolves as a promise

Currently all of the dill base widgets live in one file. This needs to be changed to have multiple files to logically split the functionality up.

So that something like this

 var marketList = new this.Widgets.MarketList();
 return marketList.clickItem(title);

can become something like this.

return this.Widgets.MarketList.forge().clickItem(title)

consider the following DOM

ul
  li
    a
  li
    a
  li
    a
  li
    a

and the following widget

Dill.List.extend({
  root: "ul",
  itemSelector: "a"
});

the selector that is generated for each list item is

ul a:nth-child(n) which will never be correct, since the nesting is > 1 node deep from the root.

dill --config-path=config.yml

Basically this should replace all of the other CLI flags such as driver / --require ect ect
see https://github.com/mojotech/dill.js/blob/master/src/dill.coffee#L5

the syntax hopefully will look something like this

- require
  - features/
  - lib/
  - common/
  - widgets/

- driver
  - chrome

The Driver setup is very configurable and simply providing CLI args is not going to be enough for most people. Thus this method should be configurable and or overridable.

https://github.com/mojotech/dill.js/blob/master/src/support/index.coffee#L65

I'm not able to run my tests with node v10

It looks like dill.js extends Object with a function named '$'

Coffeescript uses the the dollar-sign as an object member in the parser.js file
yyval = {}
...
yyval.$ = vstack[vstack.length - len];

Using node v8, the assignment operation over-writes yyval's dollar-sign variable and everything works properly.

Using node v10, the assignment operation fails, yyval's dollar-sign variable remains a [Function] and the parsing fails.

Should these files be gitignored?

#   lib/
#   src/dill.js
#   src/environment.js

See this commit for a guide.

MarionetteLabs/marionette-integration-tests@fb25b14

We can follow mochas pattern an allow people to pass a -g flag or something like this.

Another nice option would be to do

dill --only feature_file.feature:33

The rational being that is more closely resembles the current JS ecosystem environment get by index methods found in backbone collections and jquery selectors.

https://github.com/mojotech/dill.js/blob/master/src/support/Widget.coffee#L109

Dill.js is hard to get your head wrapped around.
A video that steps someone through writing their first test would be super super helpful.

Currently the stack traces are insane, since it is going through the promise API as well as webdrivers internal queue.

I think it should be quite possible to make these stack traces much shorter and more legible via a custom error base class.

I think the best way to test dill is going to be to actually use the framework to test some fixtures. We can then make assertions about the return values of the dill.js widgets.

Another approach would be to stub out the selenium piece and then only test the dill.js interactions with the stubbed selenium.

I am open to either.

this.Widget.Form.extend(function() {
  this.getFoo = function(){...}
...
})

Should be the same as

this.Widget.Form.extend({
  getFoo: function(){...}
...
})

This will allow for a friendlier interface for creating custom classes.
Under the hood not much will change, this will basically add some public interface sugar.

Related to #49

However instead of intercepting http requests this command will insert a script tag at the bottom of the page with a users fixtures.

Driver.addFixture({some: "object"}).then ->

This is currently only on the raw webElement we should proxy this from within the widget.

This should be an opt in feature.

Currently when you have an unimplemented step cucumber gives you a function that has a callback argument. This does not apply in our context since you are supposed to return a promise and or flat value to resolve the step.

We should fix this.

https://github.com/yeoman/update-notifier

more and more I find myself doing this in my widgets

  return this.Widgets.MarketItem = this.Widget.extend({
    root: '.marketplace',

    description: function() {
      return this.read('.market-description');
    },
    vendors: function() {
      return this.read('.vendor');
    },

    format: function() {
      return this.read('.format');
    },

Where this is no more than a mapping of selectors to methods, it would be handy to be able to define a shorthand hash like

  return this.Widgets.MarketItem = this.Widget.extend({
    readable: {
      description: '.market-description',
      vendor: {
        // allow for custom matchers
        // such as by inner text
        selectBy: "contents",
        matcher: "foo bar zap"
      }
    }
  });

Which would then expose

MarketItem.read('description').then(function(contents){....});

Hovering over an element in chromedriver / webdriver / phantom is really hard to do

We should add a method to the widget base to abstract this.

teampoltergeist/poltergeist#106
http://stackoverflow.com/questions/14692607/how-to-mouseover-on-a-webelement
http://stackoverflow.com/questions/17695289/webdriver-mouse-hover-in-chrome-stopped-working

It should wait for a newline / return from the user on the terminal before continuing.

@ryancoughlin is leading up this process. Feel free to share progress on this issue.

Right now there are 0 instructions for how to use dill.js on a project. That makes this lib basically unusable. We should put together a basic readme file that contains the steps needed to test a basic static html page.

This will make working with a dill collection list much easier.

myList.map ->

myList.filer ->

Setting up a CI env can be hard, we should give people a base docker box to use to ease the use of this tool.

Cucumber can be a hard sell for people, This however does not invalidate the fact that Dill is a great wrapper around WebDriver.

Dill should be able to used in standalone mode.

I think currently this is possible however we do not show people how to do this, should be quite simple.

this.Widget.Form.extend({
    root: '.projects-root',
    fields: ['name', 'description'],

Currently if you have something like the above widget and you call submitWith on the widget and do not pass name, name will be filled with undefined as compared to retaining its existing value.

Driver.stub("http://wow.com/api/tom/22", {data: struc}).then ->

It is naive to think that everyone who is interested in writing javascript integration tests has the time / ability / permissions to change the server on which the front end app interfaces. Providing a stub interface allows users to fake API requests with fixtures to easily add integration esk tests for SPAs.

http://chromedriver.storage.googleapis.com/index.html

Currently filter is helpful when reducing a list to an array of results. sometimes however you just want 1 result. It would be excellent to do this

MyListInstance.findWhere(function(){...}).then(function(widget){...})

For extra points getAttribute should take a flat string or an array or attributes to return.

currently you have to do something like this

return this.Widgets.BeakerFrame = this.Widget.extend({
    root: 'iframe.my-iframe',

     focus: function() {
         return this.driver.switchTo().frame(0);
     }
});

seems prime for abstraction into an iframe widget.

currently the message is like

array length<1> to deeply eql array length<1> which is really hard to debug. We need to add a visual diff like mocha does.

So that you can check any element within a widget and not only the root.

https://github.com/mojotech/dill.js/blob/master/src/widgets/Widget.coffee#L71

https://github.com/mojotech/dill.js/blob/master/src/widgets/Widget.coffee#L69