I am facing a couple problems while testing our private meteor packages that I would like to share with you.
Nyej already pointed out some particularly painful requirements. I’ll still describe my very own concerns first:
We have 2 apps, that work together much like complimentary services, and that works great! We are using a git submodule on the packages directory to share the packages and so far it has been enough for us even if it is far from being comfortable, move too 100% npm will help fix that.
While testing our packages with test-packages, we followed the help guidelines about unit testing which is to use meteortesting:mocha, well actually it wasn’t working as expected so we switched to cultofcoders:mocha but that shouldn’t change much.
The guidelines talk about using chai which we do, but it requires to run meteor npm install --save-dev chai which will include the package even on development bundles, not just tests. Which is simply too bad, but we can deal with that. The problem I see is that my package has no mean to work for anyone without using this command too, which means it is absolutely not portable… I could use Npm.depend but that would depend for all bundles.
Here’s what I have found so far: cultofcoders:mocha implies a package named practicalmeteor:chai which wraps and exports chai. It is my understanding that in my package if I use api.use(‘cultofcoders:mocha’), my test scripts should have access to chai, but they do not! So is there something wrong with imply? or export? Or just plain package testing?
Basically, from what I see around in the forums and the documentation we are a bit too far from painless packages testing. There are two main goals I think we should aim for: Allow everyone to very easily test your packages, so they can more easily contribute. Make packages completely independent of a meteor application for tests (now they very much rely on the package.json at the very least)
I’d be very glad to hear from others how they handle all this as we are not happy with our current setup and find it cumbersome.
https://github.com/hubroedu/meteor-mocha/ This guy took my fork of mocha, stripped coffeescript, no longer depending on packages for chai, and also gave it a beautiful design. I love it.
Thank you, will have a look! But it does not fix the requirement for my APPLICATION to have chai installed just to test my packages, and no one else but me could test them without have a (simple) note on how to test it.
Yeah something like that seems pretty interesting. We currently do the same thing, just the PACKAGE_DIRS environment variable needs to be defined so yeh, pointing directly to the folder of a package would make it easier to test it. Although, we might also like to test all packages, so we should be able to define either the directory of a package or a directory containing package directories.
The command line is just sugar coating what we have so far, I don’t mind requiring the PACKAGE_DIRS to be set, this is not the main problem… It is more about the package itself not being self-sufficient, the application running the tests needs to be correctly setup. Imagine if I was using 3 open source packages, that I would like to run tests against because I decided to make some private changes, if they had 3 different testing frameworks, I couldn’t be able to test them at the same time, or would at least need to install all the dependencies on my application, which in turn should absolutely not need those for development.
Yes, this was a borderline example… It was just to express the problem about the package depending on the application running the tests. It is in no means close to NPM packages that usually express all the requirements.
I think that a good step in would be Npm.TestDepend or something similar in the package.js. This way, the application does not need to define the required test packages.
Thank you very much @serutan, your addition is much appreciated. Still it really feels like a workaround than a fix… But usable enough for my use case, so I take it.
I love it.