Which testing frameworks are popular today - end 2018?


#1

I have the strong impression that the current chapter for testing in the meteor guide (https://github.com/meteor/guide/blob/master/content/testing.md) does not really reflect how the community here does testing.

The current testing chapter mentions some outdated frameworks and leaves out mentioning a lot which I found by a research - https://github.com/meteor/guide/issues/888 and https://github.com/meteor/guide/issues/672 are two examples.

The main testing framework currently seems to be mocha. The docs there need to be improved https://github.com/meteortesting/meteor-mocha/issues/80 but there’s also https://github.com/cult-of-coders/meteor-mocha which is a fork of https://github.com/practicalmeteor/meteor-mocha, making it usable for Meteor 1.6.x and newer, making it possible to show the results of both server and client tests in the browser. @diaconutheodor would be nice if you would join the conversation.

On the other side I also found some people playing around with Jest (https://blog.meteor.com/real-world-unit-tests-with-meteor-and-jest-3d557e84e84a, https://www.npmjs.com/package/jest-meteor-stubs) which I mainly started looking into because they support snapshot testing (https://jestjs.io/docs/en/snapshot-testing). It could be that this also is more suited for creating unit-tests, I don’t know. @rdickert, I also want you to join, because you wrote the article.

What do you use? Which is (as of your opinion) the better choice to take and should be included (removed, replaced, updated, kept) in the guide?

When I see this thread settling, I’ll create a PR to the repository of the guide.

This thread is meant as a fork of Testing guide article - providing a place to discuss which of the frameworks the testing-guide should include.

  • Mocha (meteortesting)
  • Mocha (cult-of-coders)
  • Mocha (practicalmeteor)
  • Mocha (dispatch)
  • Mocha (other)
  • Jasmine (sanjo)
  • Jest
  • Tinytest
  • Other (please explain)

0 voters


#2

Just to show off how we do testing:

We currently do all our testing (unit and functional) using meteortesting:mocha in combination with the npm packages chai, sinon and the meteor package johanbrook:publication-collector.

Another bunch of tests is run by creating a special version of the meteor application, containing xolvio:backdoor, where we do end-to-end tests using chimp and cucumber by remotely controlling a browser. These tests could easily be written by one of our clients who wants to write his own tests against our application.


#3

Mocha+puppeteer+xolvio/backdoor seems like a contender for replacing chimp/chimpy for ui testing, especially since chimp/chimpy doesn’t seem to be maintained anymore


#4

Heard a lot of good things about Cypress, but haven’t dived in yet.


#5

I also recommend this: https://github.com/hubroedu/meteor-mocha this is a fork of cult-of-coders:mocha, with coffeescript stripped and a sexier design! :smiley:


#6

@moberegger, @cloudspider, @sabativi, @gywem1989, @bduff9, @primerlabs could you please describe how you set up Jest? Are you only writing unit-tests by mocking away all of Meteors libraries or are you also doing integration tests where you test your code in conjunction with the full Meteor framework? If yes, how have you set it up?

I want to get this info to improve the testing chapter - since you represent a fourth of the voters and I don’t have a good concept of how you’d write integration tests with Jest for Meteor.

@zodern, @veered it would also be nice to hear 2-3 sentences from you, since you voted for “other”. Even if you only tell that it’s something internal or outdated would already be enough information to me.


#7

We’ve been using Chimp for testing


#8

Jest & React Testing Library


#9

Are you only writing unit-tests by mocking away all of Meteors libraries

That’s what I’m doing, yeah. I wouldn’t gleam too much from that, though, because I have been primarily doing it to learn TDD and better testing practices in general. Jest just makes it easy for me. Mocking the Meteor stuff is necessary to get anything working in that environment.

Using Meteor’s out of the box testing wouldn’t teach me much about DI, pure functions, and things like that, because it facilitates all the side effects for you. That feels better suited for larger integration tests (or E2E?) that I’m just not interested (… ie. capable :() in right now. Baby steps, I guess.