How to manage large unit test suites?

We’re getting to a point where our test suites are so large, it’s slowing us down.

Our main unit test run, with close to 2000 tests, takes 16 minutes on a top-specced macbook, which we’ve split in 3 smaller suites on CircleCI to speed things up (this was a game-changer for us btw, and also allowed us to park flakey tests in their own “flakey” test run).

There are various things we could do to shave off percentage points off of this, and probably up to 30% faster. But if we wanted to make it 5x faster, I don’t think we’d make it.

Our main issue is that most of our tests need the DB, and we wipe it between every unit test. We’ve used hwillson:stub-collections in the past, but it made our tests much less trust-worthy, as all sorts of other packages would not work, and therefore you’re not really testing your application properly.

I’m left wondering if there are some different ways to dramatically speed up tests, either through parallelization, better mocking, or something else entirely?

1 Like

What testing package are you using? Meteor-Mocha? From the looks of it, we may reap some performance benefits if the underlying libraries get updated. Also, are tapping in a real mongo database or an in-memory one? I’m in the same boat as you and thinking of solutions too. Honestly I’m wondering if anyone got jest working with Meteor.

EDIT: I did encounter a test setup that was using jest at Unchained but I’m unsure whether running an entire meteor app against the test suite is efficient. You may do the same and invoke the methods using web sockets as if they were external APIs. I’m just providing ideas as testing in meteor is awkward :man_shrugging: