My team recently upgraded our project to Meteor 1.3.1, and we’re in the process of implementing the new testing features. I read the testing articles in the Meteor guide and studied the Todos app to get an understanding of how it all works, and have been able to get some trivial tests running.
But, I hit a roadblock when trying to get testing working with packages. Our project is structured using the 1.2 “packages for everything” style. The approach I am trying to take right now is having each package contain its own tests. This way, we could have unit tests and integration tests “living” in the correct spot, and we’d have the option to isolate the tests we’d like to run to a specific package. However, the meteor test and meteor test --full-app commands won’t pick up any tests sitting in our packages.
It looks like I have to use the meteor test-packages to run and tests inside a package. Even though this works, I lose the flexibility of having unit tests and integration tests, and lose the option of running one type vs the other. I also wouldn’t be able to run both ‘app’ level tests and ‘package’ level tests at the same time.
Basically, what I want to do is to be able have unit (.test.) and integration (.app-test.) tests at both the package level and app level, and be able to run all of my unit tests at the same time, or all of my integration tests at the same time. Is this possible? If so, how would I got about setting something like this up?
StarryNight has been working for the past year on the problem of having isomorphic unit, integration and acceptance tests available at both the package and application level. Suffice it to say that we created a separate utility that scans the application and packages, and builds up a test runner script for the different scenarios and launches the appropriate runner. Commands look like the following:
It’s a single utility that runs the package-verification tests across our entire Meteor track, as well as the acceptance tests for demos in the Application Catalog.
Acceptance Testing
To get all of that working (at least for acceptance tests) across both packages and apps, we had to build up a nightwatch.json file with a file-scanner, and list out all the paths we want to test. Once we had this file, we naturally started wanting to pick up acceptance tests from packages, and run them as part of our application level testing. Which is how we got started on this problem.
Integration Testing
For integration testing, Gagarin has taken a totally different approach using file globbing patterns. It’s proven to be robust, and lets us run package vs application tests by simply specifying which directory we want to parse. Once we had a second framework that supported both package and app level testing, that’s when we stopped developing the --framework flag, and began developing the --type flag.
Unit Testing
StarryNight has had support for SpaceJam since it’s first version; although, honestly, it hasn’t seen a lot of TLC since it’s initial integration. Personally, I use Gagarin’s modified version of Mocha for most of our integration tests; and prefer acceptance testing over unit testing. So, generally speaking, SpaceJam support has just sort of been sitting there.
That being said, Meteor 1.3.1 looks great; and we’re excited to be able to swap out the old SpaceJam integration with meteor test --full-app and newer spacejam support.
tl;dr
StarryNight is close to having something that will do what you’re asking; but needs to update it’s SpaceJam support. Gagarin has a good file-globbing feature that can do package and app level testing, but only does integration tests.
@awatson1978 just wanted to say that you’re awesome and thank you both for your work on starrynight (which is very cool) and also for your frequent intelligent contributions to various threads on the meteor forums. where so often, the forums seem clogged with trolls and melodrama, i find i am almost always edified by your posts.
Thank you for this. We’ll look into all of these. Might be a bit before we can start implementing everything, but I’m sure I’ll be bothering you again when we do
