Test for "meteor run" success

testing
1

I’m sure this is straightforward, but I haven’t been able to figure it out…

What would be a way of testing that the meteor run command finishes successfully?

Elsewhere they would sometimes call this is a smoke test…

TIA :smiley:

2

Meteor normally will not return but instantiate itself as a (web) service.

If you place an exit() somewhere during server startup files, you may stop that with no sense.

If you want to check if the service is available you can use curl on localhost and check for OK 200

3

Thanks for your reply, @tomfreudenberg

For testing, I’m trying to stick to the guide’s recommendations.

Up until now, practicalmeteor:mocha has sufficed. But I’m open to any of the tools suggested in the guide… https://guide.meteor.com/testing.html#mocha

I can think of two more questions…

  • Without changing the server startup files, is it possible to have a test that checks for meteor run success?

  • If the server startup files have to be changed, are there any examples somewhere that can point me in the right direction?

Hope this makes some sense!

4

Development and Unit tests or to check that a service “in production” is online - are different tasks.

Follow the guide for the first ones

To simple check service availibility, start your meteor app, open a second session on the server, use curl

curl -L --silent --head --output /dev/null --write-out "%{http_code}\n" http://localhost:3000

P.S.: Exiting the startup process should be a no go

5

mmmh… maybe I’m not being clear. Sorry about that.

I’m not imagining a production test yet.

I’m running into problems because changes that break the build will sometimes be checked into git.

Say last week for instance, there was this particular commit where we couldn’t run the app. We would type meteor run at the terminal and it would crash with something like the following…

I20160618-00:21:49.254(-5)? Exception in callback of async function: Error: user_id must be a string
I20160618-00:21:49.257(-5)?     at getErrorObject (packages/aldeed_collection2-core/lib/collection2.js:437:1)
I20160618-00:21:49.257(-5)?     at [object Object].doValidate (packages/aldeed_collection2-core/lib/collection2.js:420:1)
I20160618-00:21:49.257(-5)?     at [object Object].Mongo.Collection.(anonymous function) [as update] (packages/aldeed_collection2-core/lib/collection2.js:173:1)
I20160618-00:21:49.258(-5)?     at [object Object].upsert (packages/mongo/collection.js:676:15)
I20160618-00:21:49.258(-5)?     at personFromTmp (imports/api/tmp/lib.js:68:25)
I20160618-00:21:49.259(-5)?     at imports/api/tmp/lib.js:32:9
I20160618-00:21:49.259(-5)?     at Array.forEach (native)
I20160618-00:21:49.259(-5)?     at imports/api/tmp/lib.js:19:10
I20160618-00:21:49.259(-5)?     at runWithEnvironment (packages/meteor/dynamics_nodejs.js:110:1)

My bright idea is that somehow I can use testing to minimize these headaches.

I’m looking for a test that says to people: your code crashes app.

Can you imagine any Development or Unit tests that would address this use case?

Thanks for your reply. Hope this makes some sense.

6

The traditional way would be to use

meteor run --once

and check the exit status.

7

Well :slight_smile: with the complete question this makes sense.

Should the job has to be run manually by developers before they commit or do you want to create it as a hook to git?

In addition, without senseful number of tests to check, you can’t prevent yourself against miss-commits.

Btw. Travis is e.g. handling such things to check if parts of the sources are breaking the system.

@robfallows also when using --once the command will daemonize but not auto restart. So I guess its nothing what can help.

8

Simple idea:

Use an ENV-VAR like MY_TEST_STOP=1 and set a Meteor.Timeout with an exit(0) after e.g. 15 seconds if found that process.env.MY_TEST_STOP is set.

1 Like