Added new Qunit build process that will browserify the contents of `test/integration/lib` into the QUnit browser, allowing much more modular testing, including unit testing of our modules in our target browsers.
Made a basic unit test file of this form for the new encryptor module, which fails miserably because I've only just begun to work with it.
I've started with this blog post as a starting point, and will be adjusting it to our needs from there:
http://qnimate.com/passphrase-based-encryption-using-web-cryptography-api/
* Add UI Testing Framework and Simple UI Test
Added a Testem configuration that launches a Qunit page with an iFrame that builds and loads our mock-dev page and can interact with it and run tests on it.
Wrote a simple test that accepts the terms and conditions and transitions to the next page.
I am not doing any fancy redux-hooks for the async waiting, I've simply added a `tests/integration/helpers.js` file with a `wait()` function that returns a promise that should wait long enough.
Long term we should hook into the app lifecycle by some means for testing, so we only wait the right amount of time, and wait long enough for slower processes to complete, but this may work for the time being, just enough to run some basic automated browser tests.
* Separate UI tests from normal unit test suite
* Add UI tests to CI test script
* Add testem and phantom to circleCI pre-script
* Fix circle pre script
* Move pre scripts to dependencies key
* Remove phantom from build deps
* Fix testem runner page
* Add promise polyfill for PhantomJS
* Skip PhantomJS in testem
* Run browser tests in parallel
* Fix promise usage?
* Correct skip usage
Added a Testem configuration that launches a Qunit page with an iFrame that builds and loads our mock-dev page and can interact with it and run tests on it.
Wrote a simple test that accepts the terms and conditions and transitions to the next page.
I am not doing any fancy redux-hooks for the async waiting, I've simply added a `tests/integration/helpers.js` file with a `wait()` function that returns a promise that should wait long enough.
Long term we should hook into the app lifecycle by some means for testing, so we only wait the right amount of time, and wait long enough for slower processes to complete, but this may work for the time being, just enough to run some basic automated browser tests.
Dan Finlay
Kevin Serrano
Dan Finlay