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.
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
@moberegger, @cloudspider, @sabativi, @nachocodoner, @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.
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.
That guide page has always been political and weirdly biased.
We’re still using Nightwatch for E2E testing after close to 4 years. Have used it to refactor core business logic and UI workflows from PHP to Meteor 0.5, then Backbone to Blaze to React. It’s been a rockstar for us, and has integrated with Meteor fantastically via it’s detailed config file, which we store as .meteor/nightwatch.json.
Nightwatch v1.0 ditches the old Java Selenium Hub, and uses direct Chromedriver functionality, so it’s now 100% V8 interpretor, instead of just having a javascript API. Nightwatch also got a big boost last year when Walmart created an extention for use with TestArmada.io.
Along those lines, Webdriver.io is the new hotness in the E2E testing community. It was the first framework to ditch the Java based Selenium hub for pure V8, and is now rolling out features like video recording of test runs.
For the E2E section of the testing article, take a look at the NPM numbers, which I think speak for themselves.
We’ve been doing extensive testing with Cypress the past 3 months, and unfortunately it doesn’t live up to its promise that it’s not flaky. There are notable differences between the CI and visual version, as well as running Cypress in Docker. It’s very cool, but our overall feeling is that it is not that mature yet.
