With the release of Meteor 1.3, we’re excited about one feature in particular that will make a new style of testing within your Meteor apps possible—the full app test. We think this feature is something unique to a full stack framework like Meteor which enables a whole new style of testing.
Meteor sits across the client-server divide in a fairly unique way, and to properly test code that spans that boundary, you’ll often need a way to run a test that itself crosses that boundary. That’s where a full app test shines.
Meteor is a full stack framework
The challenge is that logical sections of your code that should be tested together span both sides of the client-server divide. Perhaps you have a publication you subscribe to, and a method that you call from a single page in your app, and you want to ensure that the publication behaves correctly on that page when you make a change via the method. Or maybe you want to make sure that routing to a particular part of your UI loads the exact data from the server that it needs.
Compared to other frameworks, Meteor has a unique opportunity to address this challenge as it has built from the ground up to run code on both sides of the stack. Whereas in another framework you might just test that the server handles the publication and method combination correctly in isolation, with Meteor you can build an integration test that crosses that boundary:
Typical web stack testing:
Meteor full app testing:
How it works
When you start up a Meteor app in test mode it runs a special “testing” Meteor application. Typically you start a test run by connecting a browser to that application — any client tests run in that browser, and the server tests are kicked off on the server and reported in the browser as well.
When you run your application in normal test mode (meteor test ), the testing application only loads your test files, both on the client and the server, but not any of the files that it ordinarily would that kick off your application. What this means is that your test files can import any code that they wish to test, but there’s no methods or publications available on the client and no router on the server (for instance).
This is great for unit tests and simple integration tests! Typically this is the mode you’d use for these kind of tests.
Full app test mode
However, when you run in full app test mode (meteor test –full-app ), your entire application is loaded as usual, with your full app tests on top. This allows your tests to run in the context of the application, and do ‘application’ type things like routing, calling methods and the like.
In this way a full app test is closer to an acceptance test than a typical integration test. The big advantage is that a full app test can hook anywhere into the stack, both on the client and the server. This enables you to write ‘white box’ acceptance tests rather than being restricted to ‘black box’ testing by using a webdriver such as selenium.
Full app tests in Meteor are not a new idea; the Velocity project allowed something very similar and a lot of the pioneering work done there informed the design of this mode.
Also, the Gagarin tool (inspired by the Lokka project) allows injection of test code into a running Meteor app, which allows for a lot of the same techniques driven from a process outside of the main Meteor application.
With the release of Meteor 1.3 and the new testing modes, we expect the future of testing in Meteor is just taking shape. We look forward to the development of new community tools to make testing of Meteor apps easier, more thorough and faster than ever. We’re excited about what’s to come!