2020: Best test packages

testing
1

Hello, friends. I am hoping to find out what people are using for their production apps in 2020 for Meteor unit, integration, acceptance, load, etc testing.

Do people feel the best resource for newbies to begin writing tests is the official Meteor doc, meaning: does this doc use people’s preferred packages?

Thank you.

2 Likes
2

I still use what’s preferred in the docs. For Meteor projects, as well as packages, I use for Unit and integration testing

Meteor packages

  • meteortesting:mocha
  • lmieulet:meteor-coverage
  • johanbrook:publication-collector

Npm packages

  • chai
  • sinon

Works for me very well. When developing pure NPM packages I think jest is the best choice.

For CI, however, I mostly moved to use GitHub actions.

2 Likes
3

I second @jkuester’s list, those are my favorites.

I wrote one that is kind of useful called hexsprite:mock-mongo-ids

It’s a useful package if you like to use snapshot testing for an array of mongo documents.

This package is useful because it replaces randomized mongo Ids with ones that are deterministic. So multiple test re-runs will always have the same ids.

It’s tightly integrated with meteortesting:mocha at the moment but open to issues / PRs if anyone wants to integrate with something else.

For CI I’m using Google Cloud Build. But someday I could see moving to GitHub actions.

1 Like
4

cypress.io for e2e tests

3 Likes
5

Has anyone experience with puppetry? It is like “recording” the e2e workflows and saves them as code, which you can then use to run the tests. Sound very promising to but it would take a good amount of time to move away from our existing tests.

1 Like
6

For E2E testing, I’ve had good luck recently with TestCafe.

I’ve built a sample app for my class called BowFolios that illustrates how to write E2E tests for a Meteor application using TestCafe and integrate it into CI using GitHub Actions.

Only tricky part for Meteor is that for CI, you want to invoke TestCafe with the -q flag:

https://github.com/bowfolios/bowfolios/blob/master/app/package.json#L42

And, for more complicated apps with a long startup, you might also put a wait() call into your first acceptance test:

https://github.com/radgrad/radgrad2/blob/master/app/tests/landing.page.js#L11

But otherwise very straightforward.

Philip

2 Likes
7

RE: waiting for e2e tests, I use something in bash to hold off invoking my test suite until :3000 returns 200

# wait until server is fully loaded
while [[ "$(curl --max-time 300 -s -o /dev/null -w ''%{http_code}'' localhost:4000)" != "200" ]]
do
  sleep 1
done
1 Like
8

There are npm packages existing to wait for ports and sockets to become available. This is what we are using

1 Like