I come from the Rails world where it is extremely easy to get up and running with minitest or rspec. Now that I mostly work with Meteor, I find it very difficult and annoying to test apps. I’ve been using cucumber and jasmine with velocity and have tried following the Meteor Testing book but I seem to run into error after error and sometimes my tests pass and sometimes they don’t. I literally will refresh the browser and the tests that were passing will suddenly fail and then refreshing the browser will cause them to pass again… It’s quite ridiculous.
I’m working on an app right now that is starting to get to a point at which it is no longer feasible to manually test features and I really need to get a test suite setup. However, I keep trying to write Jasmine and Cucumber tests and they seem very inefficient and buggy. In addition, I’m not sure I like having my tests run while the app is running. It seems to slow things down. I much prefer the Rails/command line form of testing.
Does anyone have any suggestions for how I can get a test suite set up in an efficient manner? I’m starting to get really frustrated and its making me almost want to go back to working with Rails even if I don’t get the real-time goodness that comes out of the box with Meteor.
I feel your pain… every day. I use mocha and it isn’t any less painful. I have to restart the app all the time, refresh the browser, testing slows down the app so much that I have to wait until it finishes, Velocity’s indicators are almost useless until all tests finish: seconds will go up and down, number of failed tests don’t reset until they run, when rerunning tests you don’t know how many have passed, etc.
I have no doubt that it will all work out and in the end the pain will go away. Just don’t wait for it. Everyone’s busy, everyone has jobs, companies to run, and little time to provide.
Here’s what I do to minimize the pain. I remove mocha when I’m developing and I add the tests as I code (without running them, since I don’t have mocha). After a while I add mocha back to run the tests and deal with the errors. Rinse and repeat.
I don’t know about you but I simply cannot got back to MVC, so all I can do is tough it out until the wrinkles are ironed out.
off topic: which tool mentioned recommend me for test easily with Meteor?
I want to skip all the possible suffering that you faced, thanks brave heroes!
@cottz There really isn’t a painless testing tool for Meteor at the moment. I’ve tried most of the options out there and have been disappointed with each. I’m relatively new to testing node applications and I’ve come to the conclusion that it is nowhere near as easy as testing in ruby. The community is young, though, so hopefully things get better.
@manuel I dread going back to MVC, but it seems really nice and battle-tested at the moment. haha. I’ll try and stick with Meteor, I just hope that someone figures out how to make velocity less painful.
Sam, Mike and I offer consulting and paid work with http://xolv.io/ regarding testing.
Otherwise create GitHub issues regarding your problems. At least then we know about your problems and maybe can even help.
Meteor is still pretty young compared to Rails. The work on Velocity is completely voluntary and not paid most of the time. Sam and I work on a solution for this. E.g. crowd funding the development of a milestone. Let me know if you would invest money in that.
Otherwise with time it will slowly improve.
I’ve had the same experience with Velocy and have given up on it every time I’ve tried to use it. Meteor’s Tinytest however works great if you need to run tests in a package.
@Sanjo I appreciate all the work you guys have put into Velocity. I’m sure that creating a testing framework is no simple task. I do have one question for you though… I feel like a framework isn’t really ready for production use if there isn’t a good and efficient way to test your code as the project turns into a huge mess. However, there are many production meteor apps (I have two - poorly tested though). Are people just not testing their apps? Or are they figuring out a way to test that is easy and efficient. If so, what are they doing?
I recently spent some time playing with @Sanjo 's jasmine package and made a simple story writing game: https://github.com/modweb/wordrama
There are 30+ client integration tests. Admittedly it was a bit tedious to get everything right, but after some practice things came together pretty quick.
I’ve found writing unit tests on packages with TinyTest to be very simple–all of my larger Meteor apps are built as many small packages wrapped up nicely in TinyTests.
Still, not quite as simple as Rails testing, but it’ll get there!
@jfols I like the literate coffeescript style tests! That’s pretty cool. Thanks for sharing, I’ll spend some time looking through your tests to see if I can get a better handle on how testing should be done.
I had the same problems when I started looking into Velocity. I ended up holding off on it for the time being. What I ended up moving towards instead was a microservices-type architecture within my app.
The beauty of Meteor is you can create pubs/subs for the exact data you need on the exact page you need it. All templates in my app are created with separate html, css, and js files. This creates lots of files in your application, but it’s also easy to navigate your directory to pinpoint issues.
I ended up violating the DRY law of programming as well when moving to this type of architecture, but what I ended up with was a much more robust app where small changes only affected the feature I was working on, instead of the entire application. This may not work for everyone, but I would suggest considering it until testing in the framework becomes more reliable and easier to work with.
I’ve heard of that being done, and then using tinytest to do your testing. However, I was just referring more to keeping your code compartmentalized at a level you set - template level, route level, etc. This way, if you were to remove one of those ‘compartments’, the rest of your application would not be affected.
It’s much easier to do this with meteor than other frameworks because 1) like I mentioned above the pub/sub architecture allows a high level of granularity with retrieving and displaying data, and 2) the codebase you have for a meteor application is significantly smaller than traditional MVC frameworks, meaning it’s easier to manage repeated code in different places.
Meteor provides a building block for this modules: Meteor packages.
Structuring you app into Meteor packages enables you to test a packages in isolation (Supported with sanjo:jasmine, mike:mocha-package and Tinytest).
Another important principle for testable code is the Single responsibility principle. One practical example for Meteor apps is: Don’t put you business logic in Meteor templates.
In general, I would definitely agree that Rails has way better testing story at the moment. But I think what velocity is trying to do is not to replicate exactly Rails story but to improve on it. Should I remind you of all Rails hacks like Spring which are pretty much required now to run any reasonable size test suite.
As velocity is designed to run in parallel from ground up this problem can be avoided. However, it does take a lot of time to make it right due to complexity involved.
I also couldn’t get anything to work properly (jasmine, mocha and nightwatch couldn’t be in the same project, nightwatch got excluded from velocity, random failures here and there etc etc etc). But then I ran into Gagarin (https://github.com/anticoders/gagarin). Very straightforward framework that allows to do very simple tests to very advanced tests such as how application behaves during server restarts.