Writing tests

Foxx provides out of the box support for running tests against an installed serviceusing the Mocha test runner.

Test files have full access to the service context and all ArangoDB APIsbut like scripts can not define Foxx routes.

Running tests

An installed service’s tests can be executed from the administrative web interface:

  • Open the “Services” tab of the web interface
  • Click on the installed service to be tested
  • Click on the “Settings” tab
  • Click on the flask icon in the top right
  • Accept the confirmation dialogNote that running tests in a production database is not recommendedand may result in data loss if the tests access the database.

When running a service in development mode special care needs to be taken asperforming requests to the service’s own routes as part of the test suitesmay result in tests being executed while the database is in an inconsistent state,leading to unexpected behavior.

Test file paths

In order to tell Foxx about files containing test suites, one or more patterns need to be specified in the tests option of the service manifest:

  1. {
  2. "tests": [
  3. "**/test_*.js",
  4. "**/*_test.js"
  5. ]
  6. }

These patterns can be either relative file paths or “globstar” patterns where

  • * matches zero or more characters in a filename
  • ** matches zero or more nested directoriesFor example, given the following directory structure:
  1. ++ test/
  2. |++ a/
  3. ||+- a1.js
  4. ||+- a2.js
  5. ||+- test.js
  6. |+- b.js
  7. |+- c.js
  8. |+- d_test.js
  9. +- e_test.js
  10. +- test.js

The following patterns would match the following files:

  1. test.js:
  2. test.js
  3. test/*.js:
  4. /test/b.js
  5. /test/c.js
  6. /test/d_test.js
  7. test/**/*.js:
  8. /test/a/a1.js
  9. /test/a/a2.js
  10. /test/a/test.js
  11. /test/b.js
  12. /test/c.js
  13. /test/d_test.js
  14. **/test.js:
  15. /test/a/test.js
  16. **/*test.js:
  17. /test/a/test.js
  18. /test/d_test.js
  19. /e_test.js
  20. /test.js

Even if multiple patterns match the same file the tests in that file will only be run once.

The order of tests is always determined by the file paths,not the order in which they are matched or specified in the manifest.

Test structure

Mocha test suites can be defined using one of three interfaces: BDD, TDD or Exports.

The QUnit interface of Mocha is not supported in ArangoDB.

Like all ArangoDB code, test code is always synchronous.

BDD interface

The BDD interface defines test suites using the describe functionand each test case is defined using the it function:

  1. 'use strict';
  2. const assert = require('assert');
  3. const trueThing = true;
  4. describe('True things', () => {
  5. it('are true', () => {
  6. assert.equal(trueThing, true);
  7. });
  8. });

The BDD interface also offers the alias context for describe and specify for it.

Test fixtures can be handled using before and after for suite-wide fixturesand beforeEach and afterEach for per-test fixtures:

  1. describe('False things', () => {
  2. let falseThing;
  3. before(() => {
  4. falseThing = !true;
  5. });
  6. it('are false', () => {
  7. assert.equal(falseThing, false);
  8. });
  9. });

TDD interface

The TDD interface defines test suites using the suite functionand each test case is defined using the test function:

  1. 'use strict';
  2. const assert = require('assert');
  3. const trueThing = true;
  4. suite('True things', () => {
  5. test('are true', () => {
  6. assert.equal(trueThing, true);
  7. });
  8. });

Test fixtures can be handled using suiteSetup and suiteTeardown for suite-wide fixturesand setup and teardown for per-test fixtures:

  1. suite('False things', () => {
  2. let falseThing;
  3. suiteSetup(() => {
  4. falseThing = !true;
  5. });
  6. test('are false', () => {
  7. assert.equal(falseThing, false);
  8. });
  9. });

Exports interface

The Exports interface defines test cases as methods of plain object properties of the module.exports object:

  1. 'use strict';
  2. const assert = require('assert');
  3. const trueThing = true;
  4. exports['True things'] = {
  5. 'are true': function() {
  6. assert.equal(trueThing, true);
  7. }
  8. };

The keys before, after, beforeEach and afterEach are special-casedand behave like the corresponding functions in the BDD interface:

  1. let falseThing;
  2. exports['False things'] = {
  3. before () {
  4. falseThing = false;
  5. },
  6. 'are false': function() {
  7. assert.equal(falseThing, false);
  8. }
  9. };

Assertions

ArangoDB provides two bundled modules to define assertions:

  • assert corresponds to the Node.js assert module,providing low-level assertions that can optionally specify an error message.

  • chai is the popular Chai Assertion Library,providing both BDD and TDD style assertions using a familiar syntax.