Technically possible to run meteor unit tests against running server?

Locally I’m running meteor test --driver-package practicalmeteor:mocha --port 4001 to run my unit tests, which is refreshing each time I am changing files. So this is ok for developing.

In my CI process I would like to do first unit tests, and if they are passing, I do a meteor build and deploy the application to a docker container. This is working, but running TEST_CLIENT=0 meteor test --once --driver-package dispatch:mocha as a CI stage will always take some minutes (5-15 minutes) each time, which is not very practical for unit tests. Working, but takes way too much time…

So my idea would be if it is technically possible to run a kind of meteor test server as a docker container, which is already running. In the CI unit test stage I would pull the repository (files) and run the tests with those immediatly. But is this possible with meteor at all?

I’m just wondering how anybody of you is doing the unit tests in a CI process. I can’t believe, that a simple unit test should last 5-20 minutes (depending on the hardware).

I think anybody who is using meteor in production as a (semi-)pro should have unit tests. But there is really few informations out there.

Just saw this. We run tests in circleci, and they take anywhere from 6-12 minutes. For us, a lot of that is generating/fetching assets, so if you aren’t using any particularly problematic packages, I’d expect the build times to be much quicker.

Are you doing any caching?

I think 6-12 minutes are not acceptable for just running unit tests. The reason for that is, that each time a meteor instance needs to be started. So I was thinking of creating a docker container with running instance… This would decrease running time to a few seconds…

I agree.

Unfortunately for us, we are using an mdl package that generates/fetches assets on build. Otherwise, our times would be in the 1-2 minute range, and I’d expect others to see those same 1-2 minute build times, so if your build times are 5-20 minutes, they can likely be improved without running a permanent docker container.

The other thing to consider is that building every instance from scratch simulates a real build scenario, so there is an added layer of confidence when deploying.