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
- Writing tests
- Exported variables
- Configuration
- Batteries included
- 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 atlib/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.