E2E testing in Meteor. Cypress, Chimp or something else?

help
1

What is the recommended way to E2E test meteor apps?

Chimp seems to recommended, but their seems to some fragmentation with the project.
I have found two repositories. Where is the documentation located

I have been using Cypress which I like very much, but want to consider other options before investing too much in one option?

Does any testing framework allow you to mock the meteor server?

2

We’ve been using Nightwatch to run E2E tests with Meteor since v0.5, and have successfully migrated the same codebase from PHP to Meteor; and then Backbone to Spark to Blaze to React. Using it to deploy Meteor apps in hospital environments. Rock solid; but a steeper learning curve than other setups with long run times (they can take hours, unless you enable parallelization). Supports continuous integration, GitHub deployments, mobile device farms, massive parallelization, industry support (Walmart is a backer, via TestArmada), unit test integration, and more.

1 Like
3

What made you choose Nightwatch over anything else?

It’s just that their is a lot of options available, it’s hard to choose?

I don’t want to regret investing in a particular tool down the line/

4

Initially, the choice was made because of their mailing list, which was filled with testing professionals and had a good gender ratio representation. So active community of testing professionals who were adopting Node and could answer questions. Really great API documentation, too.

It was a slog to get the integration working at first. Where to put config files, get all the different pieces working together, adapt to Meteor’s reactive architecture. But that’s all been mostly worked out and documented nowadays. It’s been a workhorse ever since.

Their config file is brilliant, and all the options have allowed us to have testing-fu whenever the runtime environment changes. Node upgrade? Meteor installed in a different spot? Package only architecture? Headless API server? Running on CI server instead of localhost? Just update the config file, and keep going.

In my opinion, it’s very much a situation where things that are easy to set up are sometimes difficult to maintain; but those that are difficult to setup are easy to maintain.

3 Likes
5

Thanks for your help.

How did you handle resetting the database and seeding it? This has been a pain point for me.

6

We use Meteor Methods to drop or initialize the database. Nightwatch can drop into the browser console during a test script, which allows us to call methods on the server. It’s a potential security hole, so we usually scope those methods to a particular environment or package.

7

I see.

When you talk about scoping the methods, would something like this be enough

if (Meteor.isServer) {
	Meteor.methods({
		'helpers.resetDb' () {
			if (process.env.NODE_ENV !== 'development') {
				throw new Meteor.Error('resetDb is not allowed outside development')
			}

			MongoInternals.defaultRemoteCollectionDriver().mongo.db.dropDatabase();
		}
	});
}
8

That’s the general idea. We actually trigger them from the client, since they’re E2E tests and we’re using an external browser. So, checking isServer would actually prevent that.

9

+1 for Nighwatch - its “pages” and “commands” are really great stuff