Hi,
I have hit some problems trying to run Velocity sanjo:jasmine server-side integration tests on my existing Meteor application, after upgrading the project to 1.3 (1st time attempting to upgrade to 1.3, I skipped all the betas and rcs). I haven’t seen anyone else reporting these issues to date.
What is the official story for supporting Velocity - based tests on the new Meteor 1.3 ( I know 1.3 comes with its own new test infrastructure which only supports mocha syntax right now)? Is it known not to work anymore?
Here’s what I have observed so far:
Tailing the jasmine-server-integration.log prints this line at the start: "=> Using velocity:METEOR@1.2.1_2 as requested (overriding Meteor 1.3)"
No tests ran after re-starting the meteor project
Changing anything under the [project root]/tests/ folder no longer seems to trigger a rebuild.
When I changed something in an application folder, I then got a bunch of package version conflicts reported in the jasmine-server-integration.log
=> Started proxy.
=> Errors prevented startup:
While selecting package versions:
error: Conflict: Constraint meteor@1.1.12 is not satisfied by meteor 1.1.10.
Constraints on package "meteor":
* meteor@=1.1.10 <- top level
* meteor@1.1.10 <- accounts-password 1.1.4
* meteor@1.1.7 <- underscore 1.0.4 <- accounts-base 1.2.2 <-
accounts-password 1.1.4
* meteor@1.1.7 <- underscore 1.0.4 <- accounts-password 1.1.4
* meteor@1.1.10 <- accounts-base 1.2.2 <- accounts-password 1.1.4
I have 1000s of lines of carefully - crafted integration tests using sanjo:jasmine in my project. I’m not panicking yet (I am in no particular rush to migrate up to 1.3, but do not want to get stuck on an old meteor version), but it would be useful if someone could suggest a way forward here.
Yes, I can confirm this, I have the same issue. I think it is because the Mirror hasn’t been updated to 1.3.
I have added it to this issue on sanjo:karma but if it is the mirror I thing that has to be updated in Velocity.
I also understand that one of the guys at Xolv.io is working on a jasmine driver which I too would prefer to avoid re visiting tests.
I am looking at the moment to see if I can see if I can fork and update Velocity and get it working locally. I should imagine this will affect quite a few people so I am hoping it will be simple and quick to sort!
Velocity itself is no longer supported since Meteor 1.3
The next release of sanjo:jasmine will use the Meteor 1.3 testing API, which effectively replaces the Velocity mirrors
There is already a release candidate for the new version of sanjo:jasmine, but I still have to release it with the final Meteor 1.3 release as dependency. The new version is also a lot simpler and less code.
I will release the new version in the next days, when I have time for it.
I will not continue to maintain the sanjo:karma package. Instead I recommend to use Karma directly with the script that I have written here. This script will also be updated to match the Meteor 1.3 code.
I have just released sanjo:jasmine@1.0.0 with Meteor 1.3 support and also new versions of velocity:html-reporter and velocity:console-reporter that no longer depend on velocity:core (only velocity:reports).
I haven’t looked into how running on CI now should work with Meteor 1.3 testing. There is a page in the guide for this: http://guide.meteor.com/testing.html#ci. With this approach we need something like dispatch:mocha-phantomjs for jasmine. Some contributions to that would be welcomed.
Personally I’m now using Karma and a node.js script for running Jasmine tests directly, which also works on CI. The new versions of the scripts will be shortly available in https://github.com/xolvio/automated-testing-best-practices.
Hi,
I have tried using the sanjo:jasmine 1.0.0 test driver in my 1.3 - upgraded application with no progress.
When i run the command:
meteor test --full-app --driver-package=sanjo:jasmine --settings=my-settings.json
I see a spinning line for 20 mins+ until I ctrl+c the process. Looking on the Activity Monitor on my host Mac, I can see the node process is writing Gbytes of data somewhere. However, when I just run the app in normal mode, it builds and starts within 30 seconds (faster than in 1.2.1).
I tried switching to practicalmeteor:mocha … that spun for about 10 mins , then reported a series of unresolved modules.
It would be really useful if someone could write up a guide on how to migrate Velocity Jasmine server integration tests to sanjo:jasmine 1.0.0 in an upgraded Meteor 1.3 app. Also some information about what to expect when you run meteor test --full-app. is the Spinning line thing expected?
We have everything integrated into local packages so that we can reuse all things within multiple applications. We are also using angular-meteor.
When I try to run the same command with Meteor 1.3, the tests don’t event start:
=> Errors prevented startup:
While processing files with angular-templates (for target web.browser):
packages/our-app-package/client/index.html: declarations have conflicting values for the 'ng-app' attribute in the following files: app/index.html, client/index.html
=> Your application has errors. Waiting for file change.
Even with driver-package sanjo:jasmine, this error occurs.
I have managed to get my application’s suite of jasmine server integration tests working again after upgrading to Meteor 1.3. In case this information may help anyone else, here’s a list of the changes I had to make:
I had some fixture code that set up special test-only Meteor methods, adds additional functions to the applicatin global namespace, database setup etc. I moved these into a new local package called ‘fixtures’ which was set to debugOnly: true. This ensures those are available to the meteor test command, whilst not being added to the main build.
Copied all of the tests from the /tests/jasmine/server/integration folder to a new top-level folder app-tests, keeping the same folder structure ie /app-tests/jasmine/server/integration. I found if I didn’t keep the folder structure, the jasmine runner treated the tests as client-side tests.
Renamed the test source files from fooSpec.js to foo.app-spec.js. I found that the Jasmine test runner would still run the tests with their original name, but the main build then tried to include and execute them. Renaming them to .app-spec.js ensured the jasmine runner still executes the tests, but the files are not added to the main application build.
Added the velocity:html-reporter package.
Executed the tests using this command line: meteor test --show-test-app-path --verbose --full-app --driver-package sanjo:jasmine --settings settings.json --port 9000
Opened a browser session to http://localhost:9000, to view test summary and re-execute the tests by refreshing the url. I notice that the tests do not automatically re-run like they did with Velocity … I seem to have to manually refresh the page to trigger jasmine to re-run the tests. Not a problem really.
I am really pleased to report that all of my server tests ran successfully. My application makes heavy use of mongodb persistence, complex server-side packages like meteor-transactions, and I did not have to edit the content of a single test source file, which I was dreading. Much kudos to Jonas and the team at Xolvio for creating the sanjo:jasmine Meteor 1.3 driver!
For the record, I did hit a couple of other issues, but I believe neither are to do with sanjo:jasmine itself:
When i ran meteor test, I got a spinning |-/| wheel for 20mins+ before the build proper started. It turned out that meteor test copies the contents of /.meteor/local/bundler-cache/linker to the new test app temporary location every time. It turns out that my project had 32Gb of files in that folder, unknown to me. Deleting the contents of that folder before running meteor test worked like a charm. More details in this forum thread.
Whilst building the application with the meteor test --full-app command, my Mac reported a build error that I had not encountered with Meteor 1.2 or before: Error: EMFILE, too many open files '/private/var/folders/86/f0_0kwdn7bjdl5mvqhm2gcsm0000gn/T/meteor-test-run1qzfzvx'].
I ran ulimit -a which reported my Mac was configured for 1200 open files. I had to bump this up to 2400 (by adding ulimit -n 2400 to my .bash_profile file) before the build was happy again. It looks like Meteor 1.3 is opening a bunch more files than 1.2 did. I hope this does not affect my production system when I upgrade that to 1.3 too!