Test workflow improvements

[tilsammans]

With these changes, testing locally should become a lot more comfortable, especially on macOS.

• document the Rubies we are using for tests
• document the need for bundler gem
• commit package-lock.json file for reproducible tests to be done separately
• switch to Poltergeist for headless tests
• test for existence of socket file
• ease the requirement for tempfile location

[tilsammans]

I was done fighting to install Qt for the umpteenth time. It's so heavy a dependency, whereas Poltergeist simply provides the correct binaries. No more need to install the full Xcode app install either, saves about 5 GB!

I eased the strict test for a Tempfile path, as these are in /var on macOS and in general, this decision is for the OS, it cannot be relied upon in specs.

Unsure if we are to ignore the npm lockfile or include it; I included it here.

[coveralls]

Coverage remained the same at 99.059% when pulling 60b0f27 on scrollytelling:test-setup-improvements into 03dc82c on codevise:master.

[coveralls]

Coverage remained the same at 99.059% when pulling 60b0f27 on scrollytelling:test-setup-improvements into 03dc82c on codevise:master.

[tf]

Great suggestions. Especially adding a package-lock.json is something I had been meaning to do. Which version of npm do you use? I upgraded to 5.3, generated a lock file myself and it turned out slightly different (including version properties with urls instead of version and resolved properties). Running npm install while your lock file is already present, removes fsevent (which I guess is this npm issue). So maybe let's split adding package-lock.json into a separate PR.

I'm fine with using Poltergeist, but it appears to output console.log by default in test results. Now there are a bunch bandwidth detection outputs in the logs. Not sure how bad this is or how easily it can be fixed.

[tf]

I'd suggest adding an else case here and failing with a helpful error message. Maybe we can use a YAML anchor to prevent duplication of these blocks since are starting to get more complex.

[tilsammans]

I will add the macro and fall back to localhost:3306, which should cover everything.

[tilsammans]

Great suggestions. I will work on this more tonight.

…

Op 25 jul. 2017 om 15:02 heeft Tim Fischbach ***@***.***> het volgende geschreven: @tf requested changes on this pull request. Great suggestions. Especially adding a package-lock.json is something I had been meaning to do. Which version of npm do you use? I upgraded to 5.3, generated a lock file myself and it turned out slightly different (including version properties with urls instead of version and resolved properties). Running npm install while your lock file is already present, removes fsevent (which I guess is this npm issue). So maybe let's split adding package-lock.json into a separate PR. I'm fine with using Poltergeist, but it appears to output console.log by default in test results. Now there are a bunch bandwidth detection outputs in the logs. Not sure how bad this is or how easily it can be fixed. In spec/support/pageflow/dummy/templates/database.yml: > socket: /var/run/mysqld/mysqld.sock +<% elsif File.socket?('/tmp/mysql.sock') %> + socket: /tmp/mysql.sock <% end %> I'd suggest adding an else case here and failing with a helpful error message. Maybe we can use a YAML anchor to prevent duplication of these blocks since are starting to get more complex. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[tilsammans]

Which version of npm do you use?

I was on 5.1, which explains the difference in lock files. I will remove this bit from the pull request.

[tilsammans]

Now there are a bunch bandwidth detection outputs in the logs.

This is when you run the test locally and on Travis, right? I don't mind those, and the output doesn't seem to affect test results. I would say it can stay as is. (Maybe even move this output away from console.log and into the pageflow object).

Other changes done.

[coveralls]

Coverage remained the same at 99.059% when pulling fa1a65c on scrollytelling:test-setup-improvements into 03dc82c on codevise:master.

[tilsammans]

I am considering using PhantomJS 2.1.1 on Travis, what do you think? I am running 2.1.1 locally...

[coveralls]

Coverage remained the same at 99.059% when pulling e2dd80f on scrollytelling:test-setup-improvements into 03dc82c on codevise:master.

[coveralls]

Coverage remained the same at 99.059% when pulling e2dd80f on scrollytelling:test-setup-improvements into 03dc82c on codevise:master.

[tf]

@aviav can you make sure the tests still pass on your machine after these changes? I vaguely remember their was something special about your setup.

[aviav]

Everything passing with flying colors, even some specs that were previously failing in my development. Of course that looked like it was related to some Qt-webkit stuff.

It also looks like I cannot set my review to 'approve' since @tf already approves, but I would approve if I could :-)

EDIT: Found it :-)