Recently the Velocity project was handed back to MDG, which we know are very busy.
This may cause concern for the testability of Meteor but after watching the talk “How to Stop Hating your Test Suite” i’m pretty convinced that this is the way forward for Meteor testing in the next year. Perhaps the built in integration testing will improve soon.
Spoiler alert… In the talk it boils down to writing less integration tests and focuses more on unit tests and end-to-end tests.
Use integration testing sparingly because they make the same exact test test time grow exponentially as your project grows even if that test hasn’t changed (due to setup and teardown).
This means that we’re in pretty great shape actually! Unit tests run very fast because we can run them outside of Meteor & Velocity. Jasmine for example can stub a Meteor.userId and return a value. I’ve done this with 2 projects with a lot of success.
End-to-end testing doesn’t require anything with Meteor so that means you can use anything like Capybara or the new hotness… Chimp.js (cc @sam)
I’m definitely looking to dive deep in to the world of Meteor testing. However I find the community lack a huuuuuuge asset to catalyse this. How to write easily testable code in Meteor. We have a very free stack. React is catching on, and several paradigms are very different from one project to the next. I’m a bit in the blue about what to do here.
Where should one use unit tests, integration tests and E2E. How should code be written to fit in to each of these categories easily? How to write prototyping code with tests in a way that you don’t have to rewrite your tests completely on your next iteration?
A lot of these things are severely missing still, or I simply haven’t found them-
It’s surely me than a tutorial with all the competed theory chapters that explain in-depth the exact questions above; the difference between the test types etc.
I definitely appreciate the time it is taking, it is challenging to write about something that is in flux!
That being said, I’ll let you know that I’m currently working on the CI chapter and doing the chapters in order. Expect that update in the next couple of days.
Out of interest, what would you want know about more than anything else about testing in Meteor?
What would be interesting is perhaps getting two views on testing. One from the single developer trying to test for expected behaviour when comparing to specifications. Tools, methods, focus.
Another from a project group perspective. A more enterprise approach. And their difference in tools, methods, focus. CI may not be as important for a single dev, but most surely vital for a company delivering a long-lasting product!
This is something I’ve been struggling with as a single dev. What tools are redundant or time-wasters for my use? Is BDD at all worth it for smaller projects? Stuff like that is as important as to how one should actually go about doing it. When is the usefullness cutoff point.
So the video will go over this a bit more than me but in general I only write integration tests for models and any kind of mission critical piece (which tends to be just a few). I try to unit test everything that’s not super hard to test. Sometimes this means not using anonymous functions.
Learning functional programming will lead to easier to unit test code. React has made this paradigm much more popular (which is why React components are so much easier to test than other views).
I tend to use Karma outside of Meteor and then load the JS according to the Meteor rules. This setup allows you to TDD (if that’s your jam) because they only take a few hundred MS to complete (focusing on one module/func is key).
I write e2e tests after the prototyping phase is over… ideally this rapid changing is done in wireframes but if not once it settles I write them. I’ve just re-wrote my old tests in Cucumber using ChimpJS and it’s been really fast and easy to setup so far.
I just add them to my karma config using the file matches and it seems to work well for me. However, I tend to write modules instead of packages anyhow.
