Unit testing of Cloud Code functions

[drbarto]

Is there a recommended way to unit-test Cloud Code functions? I couldn't find any libs or best practices that take into account the self-hosting capabilities of parse-server, and my related question on StackOverflow was ignored.

Any info on that topic from the Parse community would be appreciated!

[gnz00]

Register the hooks pointing to a local version via ngrok and then invoke the tests.

You can use the scripts here: https://github.com/ParsePlatform/CloudCode-Express
Here is how I invoke: lib/scripts/record-webhooks && parse configure hooks -b $HOOKS_URL webhooks.json

[acinader]

I've been using https://github.com/HustleInc/parse-mockdb and it works well. I'm going to try @maysale01 suggestion though too. I'll report back on which I prefer and why (not for a couple of days though).

[chrismatheson]

I found this during my search for general info on unit testing Parse applications. My plan for cloud code is essentially to extract the functions out and unit test them with fake request / response objects.

i.e. instead of

main.js

Parse.Cloud.define("doThing", function (request, response) {

split into two files

doThing.js

module.exports = function (request, response) { });

main.js

Parse.Cloud.define("doThing", require('./doThing'));

Then doThing can be tested in a spec file something like

var route = require('./doThing');

var fakeReqest = {
 .... stuff
}

var fakeResponse = {
  success: stub(),
  error: stub()
}

route(fakeReq, fakeRes)

expect(fakeRes.success).toHaveBeenCalled();

however the stumbling block I've met is not so much the "calling" of a function to test it, but the amount of things that require mocking / stubbing. Parse.Query Parse.ACL etc that will most likely be used in a cloud function. This extends to front end code as well, and there does not seem to be a standard approach for this, or at least that i can find myself :)

Its the nature of using a BaaS or any third party service that large areas of functionality need to be mocked / stubbed, however i have to admire the approach of Angular, in providing sort of pre-done stubs / helpers for this.

FWIW id personally not recommend the ngrok web hook approach for unit tests the amount of moving parts there seems a bit high to me personally. That approach seems more for E2E testing

[acinader]

@chrismatheson I do more or less what you're describing using @TylerBrock's https://github.com/HustleInc/parse-mockdb

Works like a charm.

[drbarto]

What are the benefits of using parse-mockdb instead of parse-server? The "real" server can be run as an npm module as well, so I don't really get why one should use an incomplete re-implementation of the API.

In my current test setup, I start a (local) Parse server before running the tests and have my tests communicate with the real Cloud Code functions. The only downside I see is that for a really clean test run, I would have to reset the mongodb (which in my setup runs as a normal background process on the system). I find this both easier and more realistic than mocking various layers. But I would be interested in the opinion of others on that topic.

[acinader]

i like that with the parse-mockdb i don't have to have a mongo service running. i've tinkered a little with running parse-server for unit tests and have been looking at the parse-server unit tests, but the setup is onerous to me so far. will try again at some point (soon probably) but in the meantime, the mock setup was reasonably easy to get going and has worked well.

[flovilmart]

Seems extensively answered, closing

[majidhassan]

I'm also looking for a tool to test my cloud-code, jobs (using agenda) as well as save/delete hooks.

I started with python-nosetests mainly to test parse-server functionality at the earliest stages of the parse-server release. I'm not sure whether using nosetests in that context is the best idea, though, but it's the testing tool I'm most familiar with, and it started off as a very basic testcase.

The nosetests make calls to the actual API - I have a test environment setup just for that - instead of using a mock database or API. In my opinion, that's the whole point of testing.

Currently I'm looking into expanding my tests to achieve a higher coverage, but I'm not sure if I should stick to nosetests, or if there's a better way/tool to tackle this.

[flovilmart]

You should test your jobs the same way you test any express endpoint. Cloud code supports require properly, so you don't have to define your jobs as:

Parse.Cloud.job('name', function(req, res) {
// do the job
});

You can very well have:

// lib/jobs.js

module.exports = {
   job_1: function() {},
   job_2: function() {} 
}
...

// main.js

var jobs = require('lib/jobs');
Object.keys(jobs).forEach(function(jobName) {
   Parse.Cloud.job(jobName, jobs[jobName]);
});

Then you could use requir('lib/jobs') in your unit tests.

[majidhassan]

@flovilmart Good idea! Didn't think about that.

Any ideas regarding the testing tool itself. Nosetests currently do the job, but I'd like to know, if there's a better way to test parse (or node in general) specific code.

What do you use for testing parse-server?

[acinader]

@majidhassan parse-server uses jasmine for unit tests. I've found that looking at how parse-server does unit tests to be useful in designing my own unit tests.

[drbarto]

I use gulp to run tests and mocha to write them. Mocha is great for Parse because it has good support for promises and testing async code (haven't used jasmine but it seems to be equally well suited); however, I think the test framework itself is the least interesting aspect of a Parse test setup. Here are some ideas which helped me to create a testing environment:

I use a local Parse server and mongodb to avoid cluttering my public hosted services with test data. After overcoming the initial setup hurdle, this works like a charm.

In my tests, I call CC functions via the Parse API (Parse.Cloud.run) instead of directly invoking a JavaScript function. While this requires a bit more test setup (e.g. fist create a dummy user, then call a CC function which depends on the req.user argument), it covers the entire lifecycle of a function call.

I run both CC and tests in the same process: the Parse server is started as a "before test" action and stopped as an "after test" action. This allows me to debug (e.g. set breakpoints) the test code as well as the server-side code, which has helped me tremendously in finding bugs.

The only drawbacks I have encountered with this setup is that a) it depends on a running mongodb instance, which I have to manually reset (haven't found a good way for automating that yet), and b) the mixed log output of test runner and server code can get a bit confusing.

[majidhassan]

@drbarto I have a similar setup, while using python-nosetests as for testing. Is it possible to get any code coverage using gulp + mocha?

Also, I have - in a way - automated the process of setting up a parse-server for testing. Checkout my script here. Disclaimer: May contain bugs!

[drbarto]

@majidhassan I haven't used code coverage with my Cloud Code tests so far, but just gave it a try with a tool called istanbul, which frankly I find awesome; it worked out of the box without any additional config steps, as described here, and gave me a nice line-by-line coverage report.

Your install script seems very comprehensive, I'll definitely have a look into it. For my test environment, I so far just use the parse-server node package which gets configured, started and stopped as part of the test lifecycle. This way I can run the server inside Visual Studio Code, which is the best Node dev&debug environment I have found so far. Nothing beats setting breakpoints in Cloud Code functions.