Hi guys,
ok. I got my first meteor use-case implementet and now is time to write my first tests in meteor.
I’d like to test both my code with unit-tests
and do selenium-based tests within the browser.
What is the current state when it comes to testing with meter?
I am looking forward to your tips 
Eager to hear good suggestions on this - my meteor testing experience has been less than stellar up to now.
Velocity (plus mike:mocha) looks good, but it has been flaky as hell for me, with seemingly random failures, and test cases sometimes unexpectedly running in parallel, thrashing each others data.
Maybe I’m just doing it wrong. Eager to see a well-working example.
If you want to get serious with selenium testing, try StarryNight, which is a launcher for Nightwatch to work with Meteor.
http://starrynight.meteor.com/
Clinical Meteor is going to be launching 3 new reference apps this autumn using StarryNight, including a HIPAA/FDA multi-user version of the Todos app, along with ~30 some odd packages. The first demo app will probably be available at the end of the month (It was actually published last night; but we have various documentation to write up now.)
xolvio:cucumber is great for behavioral driven tests, for testing the user experience (not for testing your internal algorithms). The Meteor Testing Manual is probably the best way to learn more about that, though be warned that the book is in an incomplete state at the moment (still very helpful though).
I’m just currently using tinytest for my unit testing of packages. I’m putting all my files in packages (rather than in client, server, lib and public folders). This way i can control how everything is being loaded.
But i am still trying to look an easier way to do e2e testing
TinyTest is particularly great if you need to audit your entire app, including core packages (i.e. if you know you’re going to need to generate a compliance report for regulatory review, it’s best to stick with TinyTest, so you get app+core coverage.
mUnit extends the core TinyTest framework with mocha-like describe/it syntax; whereas the newly released clinical:verification package takes mUnit and cleans up its API for FDA regulatory testing.
https://atmospherejs.com/practicalmeteor/munit
https://atmospherejs.com/clinical/verification
If you don’t need to generate an audit report, Velocity is going to provide a better general unit-testing experience.
I can’t help but respond to this thread. This semester, I switched to teaching Meteor from the Play Framework in my software engineering class. So far, I’ve experienced several epic wins, such as:
And one epic fail:
Leaving application-level testing to the community to figure out has resulted in confusion, poor documentation (the Meteor Testing book in its current state is IMHO not worth buying), and overlapping capability.
In the Play Framework, the lack of built-in authentication created a similar situation: a plethora of community built authentication packages of unknown quality and problematic usability. I was delighted to see that Meteor made it trivial for users to add high quality, secure authentication. It would be a significant win to do the same for testing.
Supporting “scalability” means more than the ability to throw virtual boxes at a problem, it also means enabling an application to quickly evolve and take on new functionality over time. Scaling quickly in this latter sense requires (among other things) simple, robust, and easily understood testing tools.
Velocity is cute, but it doesn’t solve the basic problem: testing is a mess. The fastest way to fix it is for the Meteor Development Group to take responsibility for providing built-in, high quality application-level testing just like they take responsibility for authentication. For example:
MDG doesn’t need to solve every corner case for testing, but it can solve a huge chunk of the most common cases with relatively little investment. I suspect this would bring over at least a few corporate users who are currently on the fence about Meteor.
Philip
I can recommend you sanjo:jasmine for unit tests. 
You can get started here: https://velocity.readme.io/docs/getting-started-with-jasmine.
For selenium-based tests you may want to check out xolvio:cucumber (https://chimp.readme.io/docs/getting-started-with-meteor-cucumber).
I used Velocity (Mocha) for over a year and I finally gave up. It’s still too painful.
I highly recommend practialmeteor:mocha together with SinonJS (practicalmeteor:sinon). It just works. The test runner is on another process and page so it doesn’t slow down your app, it reloads as expected when a change is made to the app or tests (as opposed to wondering if it picked up the changes), the tests duration is measured in ms instead of secs, again, it just works.
I have no doubt that Velocity will eventually get better and it will be a nice experience, but I got tired of waiting in pain.
Hi girls & guys,
thanks a lot for your feedback. This does not sound too good. I totally agree with @philipmjohnson that MDG should have set this up for the community asap and guidance should be included in the starter-tutorials.
Furthermore it is scary to see that a lot production meteor-packages have very little test-coverage.
So I guess I just need to start playing around with those tools… and waste(win) some time on them…
One more thing:
Can you name some good example-projects including well written tests to have a look at? 
For packages, I just follow the ones @aldeed and @arunoda were doing (well because they have Travis CI badges)… so I guess find those that has some build badges on them.
As for e2e, I have yet to find one. I’m going to brush up again on mocha or jasmine techniques and try to come up with a good way to auto-test a behavior. It would be very useful to have those things when your doing freelance work
I think one of the issues with Velocity/Cucumber is that documentation is spread out among several places:
https://cucumber.io/docs/reference
It’s difficult to know where to look for something, frankly. I know most of the client.* method calls can be found in the WebDriver docs. Beyond that, I’m not sure whether to look at the Chimp docs or elsewhere.
There’s also a huge shortage of useful tutorials on testing in Meteor. As mentioned above, the Meteor Testing Manual is a great start, but it’s only a start, and progress on it seems to be slow-going.
I realize it’s a lot of work for MDG to provide educational materials on this, as they have to include examples for both Blaze and React.
For React, @SkinnyGeek1010 wrote up this great tutorial: https://medium.com/all-about-meteorjs/unit-test-react-components-in-meteor-a19d96684d7d
So far, unlike Manuel, I’ve had good experiences with Velocity. Due to the shortage of tutorials and examples, I’m not 100% sure I’m doing everything the “right” way, but the tests pass and fail when I expect them to, so that’s good.
Yeah I was confused the first time I saw that velocity runs every reload… From my experience tests always go at least a minute in a decent sized app. As Philip kind of alluded to - a lot of pro devs would just ignore Meteor because of it’s poor testing framework. Dev’s who give testing a low priority are not really held in high esteem by the best devs - and same probably goes for frameworks.
I got started yesterday with velocity and jasmine… and I got my first tests failing. 
It all feels a bit “beta”… like the sanjo:jasmine docs talking about “better don’t use server unit-test mode as it is beta”.
… today I’ll work thru those 2 posts:
What I love about the idea of velocity is the instant integration into our workflow… let’s see how it works out and hope for the best.
Coming from Django/Python I can say:
Meteor needs a book/video-tutorial that covers those topics in meteor-style listed here: http://chimera.labs.oreilly.com/books/1234000000754/index.html (check out the index).
This book (and the accomendating video http://chimera.labs.oreilly.com/books/1234000000754/pr03.html) was a real pleasure a read, a total inspiration and motivation.
@MDG @sashko @sam : Why not take this book above as a reference to speed things up.
Awesome post! I agree with @philipmjohnson’s points. There is a Trello card that needs your voices as well: https://trello.com/c/BQ3gu0no/12-official-testing-framework
Our (Lookback’s) experience in testing our Meteor app is quite poor. We’ve used mUnit (being deprecated), Jasmine, and Mocha for package tests, and briefly tried out Jasmine for app integration/unit tests. We also tried Nightwatch for E2E tests in Selenium.
TinyTest (and mUnit) is working alright for packages. But not all code is in packages. Meteor app testing lacks:
and because of that, we didn’t want to put in the time of going through the hoops of ductaping something together. Thus we went with E2E testing with Nightwatch instead, in order to test critical views of our application for breakage when we deployed to the CI server.
It worked mostly alright, but the Nightwatch thing was never a part of the Meteor app. The syntax was kind of weird, and we had to to hacky things to load fixtures.
Then we tried out Xolvio’s Cucumber package, which also worked. But the Gherkin syntax is weird until you get used to it (personally, I just feel it’s in my way). But we discovered that the Cucumber tests would randomly fail once in a while, making us distrust our E2E tests all together.
I really, really think MDG should put in some resources (like, hire 1-2 people, like another poster said) to take what’s best of the community frameworks, and develop some fundamental patterns and packages. This, along with a built-in router, are things that should be in the core of a 1.0+ framework imo. This sounds whiny and negative, and I know MDG are swamped with stuff. But still.
I think this topic needs to be revived and more focused on past Meteor 3 release.