Vazco / Universe E2E

Complete end-to-end/acceptance testing solution for Meteor based on Mocha & Puppeteer

This package is currently in public beta, but we use it in production at Vazco.eu with success so far.

• Why?
• Installation
• Usage
  • Setting up the project
  • Running tests in watch mode
  • Running tests in Continuous Integration mode
    • Usage with Bitbucket Pipelines
  • Meteor "full application test mode" caveats
• Writing tests
  • Example test suites
• Exported variables
• Configuration
• Batteries included
  • Mocha
  • Puppeteer
• Changelog
• License

Why?

From Wikipedia:

End-to-end Testing (E2E) is type of software testing used to validate different integrated components of an application by testing the flow from start to end. It also tests the behavior according to the user requirements.

From Meteor guide:

Acceptance testing is the process of taking an unmodified version of our application and testing it from the “outside” to make sure it behaves in a way we expect. Typically if an app passes acceptance tests, we have done our job properly from a product perspective.

There is other software that would allow you to perform E2E/acceptance tests of your Meteor app (e.g. Chimp, Nightwatch, Starrynight) but we found them really cumbersome.

This package is using test drivers introduced with Meteor 1.3 and integrates more seamlessly with the whole Meteor stack.

Everything is managed inside your Meteor app, so when writing test specs you can use everything you would normally use in your app.

Installation

universe:e2e is a test driver package for Meteor.

You need to meteor add it to your app, but it does nothing unless you specify it while starting Meteor in test mode.

Additionally, you'll need to have Mocha and Puppeteer installed using npm (probably in devDependencies):

meteor add universe:e2e
meteor npm install --save-dev mocha puppeteer

This package won't be bundled with your production build, nor loaded during normal development (it has a testOnly flag).

Usage

Setting up the project

Once the test driver and npm dependencies are installed, you need to add some setup code and write first tests.

We recommend a structure where all acceptance tests are stored inside a directory that is not loaded by default (e.g inside imports/e2e-tests) and only a single entry point with all imports in order is available to the app (e.g. a main.app-tests.js file, see caveats for more info).

Inside this file, you need to call a setup function as early as possible in the app lifecycle

1import {setup} from 'meteor/universe:e2e';
2
3setup(/** extra options go here **/)
4  .then(() => {/** test environment is ready **/})
5  .catch(() => {/** something went wrong **/});

For available options check Configuration section below.

Complete setup for a working application can be found in the example project - E2E Simple Todos.

Running tests in watch mode

To run tests you need to start Meteor in full app test mode.

Example command could look like this (you probably want to add this in npm scripts):

meteor test --full-app --driver-package universe:e2e --raw-logs

Raw logs flag is optional, but it helps with displaying test results.

In watch mode app will start and reload on any file change (either in app code or in tests). You need to stop it as you would normally stop Meteor in development mode.

If you want your tests running at the same time you work on your app, you can start them on a different port (e.g. using --port 4000 flag). Or work on the same instance, if dropping database data after you stop the test runner (not between Meteor restarts) is ok for you.

Running tests in Continuous Integration mode

This package is developed to use with CI servers in mind.

In this scenario, you probably want to run the tests once and exit with code depending on tests results. This could be achieved with:

CI=1 meteor test --full-app --driver-package universe:e2e --once --raw-logs

Note --once flag and the CI environment variable - it must be set to a truthy value (but it usually already is by CI providers).

Otherwise, app won't stop with correct exit code when tests end.

Usage with Bitbucket Pipelines

Example of a bitbucket-pipelines.yml file that could be used to automate testing on the Pipelines CI.

image: vazco/meteor-pipelines

pipelines:
  default:
    - step:
        script:
          - meteor npm install
          - meteor test --full-app --driver-package universe:e2e --once --raw-logs

vazco/meteor-pipelines is a Docker image optimized for Meteor and E2E testing, and can be used on other Continuous Integration systems, if you don't mind the name :)

Meteor "full application test mode" caveats

Meteor in this mode will start your application as it normally would (but with empty DB after each start, it keeps DB data during restarts in watch mode).

It will also load files matching *.app-test[s].* and *.app-spec[s].*, e.g. my-test.app-tests.js, so we will put our testing code over there.

Meteor.isE2E flag is set to true (useful if you want to distinguish between tests made for this package and for some other test driver)

Writing tests

Tests can be written like regular Mocha test suites, the only difference is that API like describe or it must be imported from meteor/universe:e2e atmosphere package.

Inside the test cases, you can use Puppeteer API (with exported browser and page objects) to manipulate the browser and simulate user behavior. You can spawn new browser instances and pages (tabs) if test cases require such action.

At any point, you can use extra libraries like chai, faker or even any function from your codebase - the tests are running INSIDE the Meteor app (server side) so you can do anything you are able to do inside Meteor project. One example could be database reset or fixtures right inside Mocha's before callback. Possibilities are limitless.

Example test suites

1import {describe, it, page, setValue} from 'meteor/universe:e2e';
2import {expect} from 'chai';
3import faker from 'faker';
4
5describe('Registration', () => {
6    /* ... */
7    it('should fill and send register form', async () => {
8        // Generate random username and password
9        const password = faker.internet.password();
10        const username = faker.internet.userName();
11
12        // Fill form and submit using Puppeteer API
13        await page.type('#login-username', username);
14        await page.type('#login-password', password);
15        await page.type('#login-password-again', password);
16        await page.click('#login-buttons-password');
17    });
18
19    it('should be logged in after registration', async () => {
20        // Execute function in the browser context
21        await page.waitFor(() => Meteor.user() !== null, {timeout: 2000});
22    });
23    /* ... */
24});
25
26describe('Tasks', () => {
27    it('should have new task input', async () => {
28        await page.waitFor('form.new-task input', {timeout: 1000});
29    });
30
31    it('should be possible to add new task', async () => {
32        const text = faker.lorem.sentence();
33
34        // Insert text into form and submit it
35        await setValue({page}, 'form.new-task input', text);
36        await page.keyboard.press('Enter');
37
38        // Check (using XPath as an example) if a new task with this text will show up
39        await page.waitForXPath(`//span[@data-test='task-text'][contains(.,'${text}')]`, {timeout: 1000});
40    });
41
42    it('should be marked as private', async () => {
43        // Get first task handle
44        const task = await page.$('[data-test="task-item"]:nth-child(1)');
45
46        // There should not be a class name
47        expect(await page.evaluate(task => task.className, task)).to.equal('');
48
49        // Click button and mark as private
50        await task.$('button.toggle-private').then(el => el.click());
51
52        // There should be a private class right now
53        expect(await page.evaluate(task => task.className, task)).to.equal('private');
54
55        // Cleanup task reference
56        await task.dispose();
57    });
58});

More use cases like this can be found in the example project - E2E Simple Todos (based on the Meteor/React tutorial)

Exported variables

A complete list of public API available as functions exported on the server side:

• Mocha API

  • after
  • afterEach
  • before
  • beforeEach
  • context
  • describe
  • it
  • specify
  • xcontext
  • xdescribe
  • xit
  • xspecify

• Utilities

  • createBrowser (documentation can be found at lib/puppeteer.js)
  • onTest
  • onInterrupt

• Puppeteer helpers (new helpers will be added over time, PR are welcome)

  • resizeWindow
  • setValue

Helpers' code and documentation can be found inside helpers/ directory.

Configuration

Some parts could be configured to better suit your needs.

Your custom configuration can be provided to the setup method.

Example config could look like this:

1import {setup} from 'meteor/universe:e2e';
2
3setup({
4    mocha: { // example customization of Mocha settings
5        reporter: 'spec',
6        timeout: 30000,
7        // ... other Mocha options, full list can be found at lib/mocha.js
8    },
9    browser: { // options passed to `createBrowser`
10        isCI: false, // force environment default, leave this out for auto-detection
11        createDefaultBrowser: true, // set to false to prevent browser creation and call `createBrowser` on your own
12        launchOptions: { // options passed to Puppeteer launch settings
13            slowMo: 50
14            // ... full list can be found at https://github.com/GoogleChrome/puppeteer/blob/master/docs/api.md#puppeteerlaunchoptions
15        }
16    }
17});

All keys are optional, you can just call setup() and use sane defaults.

Batteries included

This package intention is to give everything required to write acceptance tests from within the Meteor app.

Below you find quick info about the software we use to make this package work for you out of the box.

If you need any extra libs/helpers (chai, faker etc.) you can import them from npm as you would normally do in a Meteor app.

Mocha

Mocha is a feature-rich JavaScript test framework, making asynchronous testing simple and fun. Mocha tests run serially, allowing for flexible and accurate reporting, while mapping uncaught exceptions to the correct test cases.

Mocha is used to run all test suites in universe:e2e.

If you want some test to be executed, you better have it inside describe/it block.

Docs can be found at mochajs.org

If you want to set custom reporter etc. you can provide options under the mocha section of our config. List of available options can be found in Mocha Wiki. Please note that only ui supported at the moment is tdd. If you want to use bdd please let us know with your use case.

Puppeteer

Puppeteer is a library which provides a high-level API to control headless Chrome. It can also be configured to use full (non-headless) Chrome. Most things that you can do manually in the browser can be done using Puppeteer.

Puppeteer is used for browser automation, unlike most E2E test runners, which are based on Selenium. Our solution is more powerful but limited to only one browser family (Chromium and Chrome). Depending on your case this may or may not be an issue for you.

Puppeteer API should be familiar to people using other browser testing frameworks. Universe E2E creates an instance of Puppeteer's browser an page for you, so you can them to manipulate spawned browser with Puppeteer's API.

Universe E2E v0.2 and earlier was based on Selenium and WebDriverIO, so you can check it out if your looking for such solution, but we're not providing support for it anymore.

Changelog

Version history can be found at releases page.

License

Like every package maintained by Vazco, Universe E2E is MIT licensed.