I am trying to get meteor to work with wallaby, so I can do instant feedback on unit testing. Thus far, I have gotten it to work with any meteor module that only uses npm modules. but anything that uses a meteor package is a non-starter because of the magic that meteor does behind the scenes to make packages work.
Here is the repo I created:
and the issue in wallaby where I have been talking to the creator of wallaby to try to get it to work:
My question is: how can I make this kind of code:
import { Meteor } from 'meteor/meteor'
export default function stuff(arg) {
return `${arg} there`
}
testable? Currently, I’ve gotten it to load the meteor.js in packages/ that meteor generates, but it relies on a huge amount of magical assumptions of things existing that don’t exist unless inside meteor. wallaby runs outside meteor, so…
Currently I’m only using Wallaby for “pure” module testing, but if I understood correctly, the wallaby config files from this repo get (parts of?) the Meteor environment working correctly inside Wallaby.
I am aware of that repo. It does not work with meteor 1.3 (most recent bug
describes the errors).
What does work is a from-scratch mantra app based on the blog example. But
to make it work, all of the meter packages are mocked and all dependencies
injected.
This is not bad on its face but means integration testing can only be done
through other means.
@gadicc you’re correct, it loads the full Meteor context (including a database when you have one running). It’s definitely a little slower for wallaby to reload the tests, but we’re still talking less than 1 second usually. Wallaby has some good caching and parallelization going on which helps a lot.
Excellent! One note: I have been corresponding with the creator of wallaby
through an issue on their public github, and he noted that adding
"instrument: false" to the packages from meteor can vastly improve the
speed. I tested this and found it reduced load time by more than a second
on my machine. It doesn’t fix the other errors, but is a simple way to
remove that bottleneck.
This basically causes wallaby not to record code coverage for the packages,
or parse the files at all beyond what babel does with them.
My personal experience is that stubbing means programming in assumptions about how a package works. It allows you to strictly test your code, but does not actually verify that you haven’t broken the connection to the package you are using.
When I was working in PHP, I had a website go down with all tests passing and full coverage for this exact reason.
What I have been doing is using wallaby only for unit tests, and using meteor test for the others. This means I always have 4 processes running in webstorm:
The meteor app
Meteor test
Wallaby
React storybook
Which is OK, I guess. But I really like the instant feedback for wallaby. It’s quite a bit slower to wait for meteor test to refresh.
I have finally updated the wallaby_server.js for Meteor 1.3. I have also added documentation at the top of the file and restructured the code to be easier to use. Let me know if you still have trouble using it.
I experienced the same issue when running wallaby with that wallaby_server.js file - it’s not able to require any meteor module. I further found it was not able to load any local modules referenced by full path, e.g. require("/imports/api/mymodule/collection") it was only able to load relative references. @Sanjo I would be happy to try and help fix but have to confess I don’t understand what the bootstrap function does - is there any chance you would be willing to explain the essence of what it does, which might enable me to attempt a fix?
