[HTML5 Client] Setup for React Tests

[MaximKhlobystov]

This PR introduces the initial test setup for Meteor React tests. Some sample test specs are added, as well as various testing packages and NPM script command.

Meteor tests have to be outside of tests folder at the time of execution. But if we store them permanently there, they are included in the build. So the test script does the following:

• temporary copies files from /tests/meteor to /imports/meteor-tests
• runs Xvfb on the brackground
• runs the test command
• removes the temporary test files
• kills the Xvfb process.

[OZhurbenko]

It also fixes the favicon.ico warning which you could see in the FF web console.

[gcampes]

beta packages?

[OZhurbenko]

All later versions work only with Node 6.x+, but Meteor is still using 4.x.
We can try to update it once Meteor updates its Node version (which is supposed to happen in Meteor 16).

[antobinary]

Meteor 16 brings in Node 8.x

[gcampes]

Why is this empty?

[oswaldoacauan]

Nice work.

Could you add real tests cases? I didn't figure out what type of tests are being added nor how should I write them for ReactComponents nor Server-side (collections, meteor stuff).

A little worried about the selenium-webdriver being on a beta version, but since tests are only for dev (no CI right now) should be fine.

Another question, are we having the tests specs on a different folder? Isn't easier to have it together with file being tested with a .test.{js,jsx} extension?

[MaximKhlobystov]

Re: having test specs on a different folder.
Good point. Although, there are a few disadvantages of putting them together with the code files, in my opinion.

1. It would be a nightmare for deployment, I assume. We definitely don't want test code to be included in the build. Meteor build doesn't touch /tests. But Meteor tests also don't allow us to place them in /tests (Meteor thinks that /tests is only for third-party testing solutions). So we store the specs in /tests, but when the time comes, we copy the whole folder into /imports, run the tests, and remove them afterwards. If the tests are next to the tested files, they will always be included in builds. To prevent that, we would have to remove them every time before running Meteor.
2. For unit tests, yes, it makes sense to associate spec files with their related source files. But it doesn't work for functional or end-to-end tests at all. They often don't belong to any particular code file.

[MaximKhlobystov]

@oswaldoacauan
We were initially planning to add the real test cases in a separate PR, but now I see it makes sense to write them here. Will try to update this PR later this week.

[oswaldoacauan]

So the best scenario should be:

• /imports/**/*.{test,spec}.{js,jsx}: unit-tests.
• /tests/**/*.js: functional, integration, acceptance, load, etc.

We were initially planning to add the real test cases in a separate PR, but now I see it makes sense to write them here. Will try to update this PR later this week.

👍

[oswaldoacauan]

Can we initialize the collections inside their respective file?

/imports/api/users/index.js

import { Meteor } from 'meteor/meteor';

const Users = new Mongo.Collection('users');

if (Meteor.isServer) {
  // types of queries for the users:
  // 1. meetingId
  // 2. meetingId, userId

  Users._ensureIndex({ meetingId: 1, userId: 1 });
}

if (Meteor.isTest) {
  // fixture data
}

export default Users;