linagora-rse/docker/doc/tests.md

Linagora RSE

# Testing OpenPaaS ESN with Docker

Unit tests and integration tests are launched with Grunt (cf Gruntfile.js at the root of the repository).
They can also be launched in Docker containers with the help of the grunt-docker-spawn plugin.

## Unit and integration tests

The related grunt tasks are all starting with the 'docker-' prefix:

- docker-test
- docker-test-unit-storage
- ...

## End to end tests

Before you can start running any E2E tests, run bellow command to prepare an
E2E testing environment:

```bash
grunt test-e2e-prepare
```

Above command will mainly pull or build required Docker images.
Once it runs successful, you can perform a full E2E test with:

```bash
grunt test-e2e
```

This is regular way to run end-to-end tests. It will create all required ESN
containers, wait for each service to be available, run protractor tests and then stop/garbage all containers.

##### Change the browser target

Tests are run against Firefox by default, but you can change by giving the BROWSER environment variable, like:

```bash
BROWSER="chrome" grunt test-e2e
```

##### Watch what is going on

Protractor will target a selenium grid, ran as a container. You can watch what happen on the browser by opening a VNC client with the following settings:

- server: the server runing the grunt command, usually "localhost"
- port: 5900
- password: linagora

##### Record a video of the run

You can ask for recording a video, only by giving some environment variables on your command:

```bash
VIDEO=true grunt test-e2e
```

Available variables are:

- VIDEO: default is _false_
- VIDEO_FILE_NAME: what will be the name of the generated file suffixed by .mkv, default is _open-paas.e2e_
- VIDEO_DIR: where will be located the generated file, default is under _videos_ of _your OS tmp directory_. So _/tmp/videos_ on Linux.

You may not be able to move backward or forward the video, if you have such problem,
try converting it to other format by `ffmpeg`, for example:

`ffmpeg -i input.mkv -vcodec copy -acodec copy output.mp4`

### E2E test in development

##### ESN code has changed

Anytime you change your ESN code, you may want to rebuild your ESN image with:

```bash
grunt test-e2e-build
```

##### ESN external services has changed

If you have newer version of service images like esn-sabre, esn-elasticsearch, etc.
You can pull latest version of them with (don't forget to build ESN images again
after a pull):

```bash
grunt test-e2e-pull
```

##### Save time by not creating all containers each time

Running `grunt test-e2e` will remove the containers after it finishes.
Instead, you can skip the containers removal to save time while you're writing
tests. By using the following command, you will reuse the same containers over
the time. So use it carefully, as for example, your database data won't be
removed between tests!

```bash
grunt test-e2e-quick
```

##### Run tests on your own browser

To ease tests creation and debugging, you can run tests against one your own local browser.

```bash
LOCAL="true" BROWSER="firefox" grunt test-e2e
```

##### Clean up

If an unexpected issue makes the container removal failing
(see `docker ps` output), you can do it manually with:

```bash
grunt test-e2e-down
```

#### Run only specified E2E tests

When you have many E2E tests, you may not want to run them all on each time you
write E2E tests for your code. In such cases, you can run only specified
scenarios by leveraging Cucumber [tags](https://github.com/cucumber/cucumber/wiki/Tags).

Let's specify a tag for your feature:

```
@only
Feature: Verify billing
```

Then test only that feature by:

```bash
tags=@only grunt test-e2e-quick
```

#### Logging

If you want more logs, use `--show-logs` option with E2E test tasks, for example:

```bash
grunt test-e2e-prepare --show-logs
```

## Docker settings

While the tests should work out of the box on a Linux platform locally, they need some additional parameters to run on Windows and OS X or on remote host.

```bash
DOCKER_HOST=192.168.99.100 DOCKER_PORT=2376 DOCKER_CERT_PASS=mypass grunt docker-test-modules-midway --docker remote
```

By using the *DOCKER\_* environment variables, we give grunt required environment variables to launch container on the *remote* machine.
The remote configuration is also defined in the Gruntfile under the container.options configuration:

```json
  {
    remote: {
      host: process.env.DOCKER_HOST || '192.168.99.100',
      port: process.env.DOCKER_PORT || 2376,
      ca: fs.readFileSync(process.env.DOCKER_CERT_PATH + '/ca.pem', 'utf-8'),
      cert: fs.readFileSync(process.env.DOCKER_CERT_PATH + '/cert.pem', 'utf-8'),
      key: fs.readFileSync(process.env.DOCKER_CERT_PATH + '/key.pem', 'utf-8'),
      pass: process.env.DOCKER_CERT_PASS || 'mypass'
    }
  }
```

Note that you may need to generate P12 certificates on OS X (As explained here http://blog.couchbase.com/2016/february/enabling-docker-remote-api-docker-machine-mac-osx).

On the docker-machine VM:

```bash
cd $DOCKER_CERT_PATH
```

then

```bash
openssl pkcs12 -export \
-inkey key.pem \
-in cert.pem \
-CAfile ca.pem \
-chain \
-name client-side \
-out cert.p12 \
-password pass:mypass
```

Please note that the password defined just here is the same which is used in DOCKER_CERT_PASS environment variable in the remote configuration above.