Move in-HTML JavaScript outside of HTML.

[markafitzgerald1]

Could go in cribbageAnalyst.js, as any of: 1) the same code, 2) a Handlebars template invocation, or 3) a combination of HTML MVC framework markup and external JavaScript code.

[markafitzgerald1]

Working solution to this issue implemented locally using Vue.js. Just need to figure out how to unit test the Vue.js initialization code in the cribbageAnalyst module, which expects document to be defined.

[markafitzgerald1]

How to unit test: move new Vue() into entry point code & unit test options & functions handed in to Vue constructor: http://vuejs.org/guide/application.html#Unit_Testing. Actual constructor call can be e2e tested.

[markafitzgerald1]

Made some progress on unit testing Vue configuration object and a little progress on end-to-end testing Vue instantiation (with Nightwatch). Approach more solid now. Will likely break current local all-in-one analyses component into sub-components prior to commit and push.

[markafitzgerald1]

Tried unsuccessfully to move #cribbageAnalyst Vue initialization options out to separate unit testable module. Failure due to Webpack not supporting that module depending on the Webpack entry module's analyzeDiscardOptions() method. Will instead re-inline the options into the entry point code, then cover that code via Nightwatch end-to-end in-browser tests.

[markafitzgerald1]

Have now locally re-inlined Vue.js initialization options, including its analyses computed property, into the cribbageAnalyst.js Webpack entry point module. Next: add automated tests of the Webpack entry point module via NightwatchJS and gulp-nightwatch.

[markafitzgerald1]

Got gulp-nightwatch running with a test that hits google.com. Next task is to automate simple HTTP server start and stop as part of Gulp pipeline via gulp-connect.

[markafitzgerald1]

Example of how to use run-sequence to start connect HTTP server, then run Nightwatch tests, then stop HTTP server: http://stackoverflow.com/a/33934969/1840078.

May even be able to replace run-sequence with plain Gulp dependency chain by returning the result of the server start call in its Gulp task.

[markafitzgerald1]

Now have a locally correct and passing e2e test of basic app happy path. Achieved by opting to start a gulp-connect server from a separate gulp process. This can be automated in Travis CI with PhantomJS as the browser, thereby allowing the project CI server to run e2e tests. :)

Note that we could also replace gulp-connect with Gulp-free connect-livereload underlying plugin, or something even more lightweight.

Next: try out gulp-nightwatch-headless as one final attempt at having a single Gulp process manage the app HTTP server before settling on the two-process approach. If two-process, try to replace gulp-connect with lightest possible Gulp-free solution.

[markafitzgerald1]

nightwatch-headless starts Selenium but not an HTTP server using its startup documents; bailing on this approach.

Next: Gulp-free lightweight HTTP server before finalizing e2e tests approach and testing out on Travis CI server. NOTE: be sure to configure Travis CI to start the lightweight HTTP server before pushing actual Gulp e2e tests to Github project!

[markafitzgerald1]

http-server looks like a decent, popular and well-supported HTTP server candidate for e2e testing purposes both locally and on the CI server.

[markafitzgerald1]

...but gulp-connect is the most popular and well-supported in-Gulp option, and sticking with an in-Gulp HTTP server option keeps all development pipeline knowledge documented in one file, gulpfile.js. Thus am probably sticking with gulp-connect.

This makes Travis config the next issue task! (Try to push one step at a time to avoid a CI server build error - step 1 = push new startServer Gulp task, step 2 = .travis.yml that runs that Gulp task prior to the default Gulp pipeline.)

[markafitzgerald1]

...also need to break up Vue.js usage into components before commit and push!

[markafitzgerald1]

Local break-up of Vue.js in-HTML usage into Vue.js <card-list> and <analysis> components complete. Now need to: 1) decide whether or not to convert existing proposed e2e tests into actual Nightwatch ones, and 2) stage changeset one hunk at a time such that Travis CI continues to build without breakage.

Leaving gulp clean task out of issue scope for the moment.

[markafitzgerald1]

Also need to get gulp coverage passing by somehow excempting cribbageAnalyst.js from the unit test coverage check, as it is only covered by end-to-end tests now locally.

[markafitzgerald1]

(Locally) got gulp coverage passing locally by adding a ! pattern to the cover.instrument configuration object's pattern property.

[markafitzgerald1]

Asserting total analysis count and other things via Nightwatch.js seems to require using the poorly documented browser.elements method and not-so-simple XPath expressions for which correctness is tricky for me to easily verify.

I'll leave such e2e tests out for now, as related multi-analysis assertion e2e tests will likely arise during resolution of likely to be resolved future issues analysis sorting (#14), similar expected points analyses (no issue yet), and duplicate analysis suppression (no issue yet).

[markafitzgerald1]

Local implementation ready for piece-by-piece merge into remote/master... tomorrow!

[markafitzgerald1]

Erroneous commit comment - 0677168 actually closes #19.