*** meteor test with xolvio:cleaner... DATABASE GONE!

1

Wow. this was very surprising !

I spent the weekend setting up a little prototype app in Meteor, and I wanted to run some tests on it. It was hooked up to a mongodb instance on compose.io, and linked via MONGO_URL as usual.

So, following along the docs here

“When your app is run in test mode, it is initialized with a clean test database.”
“As we’ve placed the code above in a test file, it will not load in normal development or production mode (which would be an incredibly bad thing!).”

I followed the instructions exactly, putting a call to xolvio’s resetDatabase in a file called “myMethods.spec.js”, and running it with

meteor test --driver-package practicalmeteor:mocha

Wasn’t I surprised to find, after a bit of confusion, that all the collections on my Mongodb (production) instance were now… EMPTY !

What on earth is going on here ?! Am I missing something ? By calling

meteor --test

I had understood this would absolutely not touch the database at MONGO_URL… is this not correct ?

2

You should not configure MONGO_URL when working on your local machine. When deploying you set them, see for example: https://guide.meteor.com/deployment.html#galaxy where they describe the --settings option.

3

Oh, wow :cry:

@sam , might be worth adding a guard against this one via warning and not running unless

export YEAH_REALLY_CLEAN_MY_PRODUCTION_DATABASE=1

or something is set, when MONGO_URL is set to anything other than localhost.

4

@alon yes that might be a good prevention for this. It can’t be an automatic detection because many test environments are running on different ip’s and other servers without issue. But yes, a basic check on localhost in that package may prevent such issues.

More in general: This is why you want to do deployments scripted, so there is less risk of manual error.

For example some of our apps cannot run without having an active configuration file. If you forget to add --settings and no environment config is available it will not boot. So the developer instantly knows something is misconfigured.

5

Hey @kelbongoo sorry to hear you had an accident! That sucks :’(

We do actually check the NODE_ENV for development as you can see here:


Did you have the NODE_ENV set to something else?

As @lucfranken has highlighted, the real error is due to setting the MONGO_URL and we can’t really check for localhost as some people (us included) do run against remote databases. The best approach is certainly to automate everything.

@alon that’s a good idea. Would love a PR, and I think we also need a PR for the meteor guide to warn people about this situtation. cc @sashko

6

:+1:

If he runs on local as developer that will be development (which is correct). NODE_ENV does not care about MONGO_URL. There is no way to prevent this behavior without locking out groups of users who use custom databases.

7

@sam, would depending on the mongodb-uri npm package to parse the URI be acceptable? (Meteor’s mongo package uses it as well)

8

@lucfranken true, doh!

@alon could we just do a simple regex like localhost|127.0.0.1 instead? just saves us extra dependency and version matching in the package, unless there’s some trick that I’m not aware of to reuse the package used by Meteor?

9

@sam, sent a PR, let’s discuss it there.

10

Many thanks for the responses - it was just a little test app with fake data :slight_smile: But it made me suddenly wonder how stable the “meteor test” command actually is.

In any case, better my little test app than Mark Zuckerburg’s production app :slight_smile:

11

@alon looks good to me, thank you. It would less code and memory if regex is used but hey if it works :slight_smile:

Did you try it?

12

Nope (and I noted that at the top of the PR), I just coded it in a few minutes on my way out.

I will try to set up a test case and maybe benchmark the effects on test speed in the next few days.

13

ok thank you and let me know