Automated tests + CI

[harlantwood]

It occurred to me today that (most of the moving parts of) the tree viz in #1 can be tested on CI pretty readily:

• factor the tree viz so that the JSON tree sent to d3 can be requested via a URL
• start up IPFS via ipfsd-ctl package
• ipfs add -r some-test-fixture-dir
• load up a headless JS browser with http://www.nightmarejs.org
• load the page in a test env using mocha + webdriver.io + phantomjs
• request the known hash of the fixture dir
• assert that the returned json (the DAG data of the fixture dir) is as expected

While this does not test D3 or the layout code, it would test all of our logic, and the connection to the IPFS API.

[jbenet]

SGTM! 👍

[harlantwood]

I'm working on this using mocha + webdriver.io
... @travisperson you mentioned e2e testing with these two, do you have any samples you like to help me get rolling?

[travisperson]

Nothing that I can share unfortunately. All the work I've done has been for
my work.

I will give you a run down of some hints and tricks that I learned though!

• The driver object you get back the browser object after the call to
  webdriverio.remote you have an object which will queue all actions. In
  all their docs they chain commands, which I kind of find ugly and error
  prone. You don't have to do this.
• Adding commands
  is powerful and awesome! I commonly used this for logging in.
• The documentation is amazing and the source is clean, all commands link
  back to their source file in the docs.
• There are webdriver.io specific commands that I found do better when
  chained. But they still work just fine without.
• I have yet to figure out how to release keys when using protocol#keys.
  I haven't personally tested anything but in the docs it states that
  modifier keys are not released so they can be integrated with mouse moment.
• I usually place all my selectors in a separate file, which is just an
  exporter object. This makes it easy to update and have effects take place
  everywhere. Also when doing react apps, you can include the same file and
  keep things consistent between tests and the app. The same goes for login
  and other info.
• Download the protractor selenium stuff. It's so nice to have it automate
  the selenium setup. You can install protractor from npm npm install -g protractor and you will get the webdriver-manager CLI tool.

https://angular.github.io/protractor/#/server-setup

You can of course set it up yourself as well.

If you have any questions let me know.

On Wed, Jun 10, 2015, 1:53 AM Harlan T Wood [email protected]
wrote:

I'm working on this using mocha + webdriver.io
... @travisperson https://github.com/travisperson you mentioned e2e
testing with these two, do you have any samples you like to help me get
rolling?

—
Reply to this email directly or view it on GitHub
#3 (comment).

[harlantwood]

Thanks @travisperson, much appreciated!

[harlantwood]

Progress report: I made a simple webdriverio-mocha-example repo which tests integration of:

• webdriverio using phantomjs
• mocha (lightly sugared with chai)
• selenium-standalone for the selenium server

After some struggles, it now works both locally and on Circle: https://circleci.com/gh/harlantwood/webdriverio-mocha-example

Next step: actually testing something useful 😉

[jbenet]

@harlantwood that's great!

[harlantwood]

I've let go of working on this for now. Once I got deep in, it seemed like most of what I was testing was actually that the IPFS API worked as expected, which already has its own tests.

Closing for now, anyone feel free to reopen if it seems like a good pathway for further exploration.