If you’ve been following along with the 1.3 release, you’ll know we have an new test mode coming. So far we’ve only supported a single test driver, but with the release of 1.3-beta.12 we now allow multiple drivers with the --driver-package option.
So this is a call for other testing package authors to have a go at updating their driver for 1.3. As you can see from the PR for mocha it may be relatively easy to do, but please ask if you need any help.
I’ve created a helper package which you can leverage to write such a package. The README for that package explains a few of the intricacies in doing so, so I won’t repeat them here.
I wouldn’t have thought it was necessary. Gagarin runs outside of the Meteor process and as such doesn’t need any kind of special test mode (as I understand it).
Similarly for any other end-to-end testing solution.
In theory, we should be able to add complete support by either a) extending Gagarin so it can be run with via the --driver-package option; or b) forking the practicalmeteor:mocha package into practicalmeteor:gagarin.
Nightwatch also has support for Mocha and unit tests. Will be looking into incorporating the test driver for that as well, so as to get the method chaining functionality. Would also like to hear thoughts from @warehouseman.
I’m not sure whether that makes sense. I mean, sure it uses mocha syntax but it runs tests in a completely different way to practicalmeteor:mocha. For a start, it doesn’t make sense to have more than one client (which is a feature of Gagarin) in our test mode. It’s just a fundamentally different thing.
Basically it comes down to the test runner either
a) needing to be launched from within a meteor app’s context
b) taking a running meteor app and poking it.
As I understand it, Gagarin is firmly in b), and the Meteor tool doesn’t need to do anything special to support it. That’s why it’s perfectly possible to use any end-to-end test runner with Meteor and we don’t need to explicitly support any of them [1].
[1] We are documenting how to use Chimp in the guide but there is literally zero code in the Meteor tool that helps with that.
I’m less worried about the test-runner as I am the tests.
Gagarin uses the mocha library. So there’s opportunities for making it isomorphic to the mocha driver. There’s a third and fourth option:
c) being able to run in either context
d) tests that can be run in either a) or b)
Tests that can run in both contexts enable refactor paths. So people can write a function as a unit test, then walk it over to be used in an integration test, and then into acceptance tests.
This is why I’d like to hear from some of the others.
@tmeasday It seems that runTests is not called on the server side, only on the client side. I usually to run a lot of the tests on the server side. Will this be added, or am I supposed to call the server side from the client side to start the server tests?
You should call a method to run them (conceptually there may be multiple clients that run the tests, which should be run on the server for each client; or at least the tests shouldn’t run until a client connects). You can look at the implementation of tinytest and test-in-browser (for package tests) if you are wondering how it “should” work.
Basically it has a publication for test results and a method to start a test run I think.
I would have thought you’d run into hard-to-resolve issues with import X from 'meteor/Y' being incompatible with Jest (and also maybe imports from inside packages). But if you have a workaround for that, you’d need your driver package to kick off the Jest process somehow.
