How to add additional libraries (e.g. sinon) to use in tests?

[marekrogala]

In some of the tests we do not use server/client calls at all (in fact, this is the case for most of our unit tests). However, we'd like to execute them with gagarin to have just one place for all tests.

How can we add additional libraries to be available to the test code which is not executed on Meteor?

For example, we'd like to use a mocking library such as sinon. We tried using meteor package for sinon, but as I understand this adds sinon to scope of the Meteor app, and not to the scope of the gagarin tests code. Currently we'll probably add sinon to package.json in a fork and use a require, but probably it should be possible to do that in a more flexible way?

[marekrogala]

The same also applies to libraries used by the code under test (e.g. the tested function depends on lodash). Is there a way to do that, or would the best approach be to run everything through server/client methods and add dependencies only in meteor?

[apendua]

@marekrogala Good question! Lets do some brainstorming here.

[nimerritt]

Any progress on this? My use case involves using Gagarin to spin up a Meteor instance exposing both a DDP connection and a REST API. I want to run integration tests against the API client which is packaged as an npm package. I would just run everything as a standard mocha test, but I want to be able to make DDP method calls on the server to setup fixtures and don't expose that to the REST API.

[apendua]

@nimerritt Interesting point. I am now trying to rethink Gagarin from scratch and I will definitely take your suggestion into account. Basically, the idea is to make Gagarin features injectable into whatever testing framework you prefer to use.

[nimerritt]

@apendua, thanks!
Great work on this project. It was a life saver where I work (attach.io) Our core functionality is split between two Meteor apps. In the main Meteor app, users create links. In the other Meteor app, people view these links. In addition we have another Meteor project serving out API and one running background services. Due to Meteor's lack of proper shutdown code on a redeploy, we have code which cleans up after an app stops. Testing all this before was really difficult, so I really appreciate the work done on this project! I'd be happy to share more details if you are interested as a sort of case-study if you are doing a redesign. I'm assuming the redesign will use the new module features of Meteor 1.3?

[apendua]

@nimerritt Good to hear Gagarin was useful to you!

As you suggested, I am thinking about Meteor 1.3, but actually I don't think that modules are going to affect Gagarin a lot because it will probably stay as external to Meteor as possible. The only delicate part is the moment when you're requesting Gagarin to run the inline fixtures on the server/client side. Trying to ensure that these snippets will have access to your app modules, i.e. you can import, will probably be the tricky part.