Overview

A thorough automated test suite is important because it:

• Ensures your application works as expected.
• Prevents regressions when new features are added and bugs are fixed.
• Helps new and existing developers understand different parts of the codebase(knowledge sharing).
• Speeds up development over the long run (the code writes itself!).

Types of tests

We encourage writing tests from a few perspectives, mainlyblack-box testing(acceptance) andwhite-box testing(integration and unit). Tests are usually written using typical patterns such asarrange/act/assertor given/when/then. Bothstyles work well, so pick one that you’re comfortable with and start writingtests!

For an introduction to automated testing, seeDefine your testing strategy.

Important: A great test suite requires you to thinksmaller and favor fast and focused unit tests over slow end-to-end tests.

This article is a reference guide for common types of tests and test helpers.

Project setup

An automated test suite requires a test runner to execute all the tests andproduce a summary report. We use and recommend Mocha.

In addition to a test runner, the test suites generally require:

• An assertion library (we recommend Should.js).
• A library for making HTTP calls and verifying their results (we recommendsupertest).
• A library for creating test doubles (we recommendSinon.JS).The @loopback/testlab moduleintegrates these packages and makes them easy to use together with LoopBack.

Set up testing infrastructure with LoopBack CLI

LoopBack applications that have been generated using the lb4 app command from@loopback/cli come with @loopback/testlab and mocha as a default, so noother testing infrastructure setup is needed.

Setup testing infrastructure manually

If you have an existing application install mocha and @loopback/testlab:

npm install --save-dev mocha @loopback/testlab

Your package.json should then look something like this:

{
  // ...
  "devDependencies": {
    "@loopback/testlab": "^<current-version>",
    "@types/mocha": "^<current-version>",
    "mocha": "^<current-version>"
  },
  "scripts": {
    "test": "mocha --recursive \"dist/test\""
  }
  // ...
}

Data handling

Tests accessing a real database often require existing data. For example, amethod listing all products needs some products in the database; a method tocreate a new product instance must determine which properties are required andany restrictions on their values. There are various approaches to address thisissue. Many of them unfortunately make the test suite difficult to understand,difficult to maintain, and prone to test failures unrelated to the changes made.

Our approach to data handling, based on our experience, is described in thissection.

Create a test datasource

As we would prefer full control of the database and even the developmentdatabase is not something we want to clean before each test it’s handy to use anindependent in-memory datasource which is filled appropriately usingtest data builders before each test run.

src/tests/fixtures/datasources/testdb.datasource.ts

import {juggler} from '@loopback/repository';
export const testdb: juggler.DataSource = new juggler.DataSource({
  name: 'db',
  connector: 'memory',
});

Clean the database before each test

Start with a clean database before each test. This may seem counter-intuitive:why not reset the database after the test has finished? When a test fails andthe database is cleaned after the test has finished, then it’s difficult toobserve what was stored in the database and why the test failed. When thedatabase is cleaned in the beginning, then any failing test will leave thedatabase in the state that caused the test to fail.

To clean the database before each test, set up a beforeEach hook to call ahelper method; for example:

src/tests/helpers/database.helpers.ts

import {ProductRepository, CategoryRepository} from '../../src/repositories';
import {testdb} from '../fixtures/datasources/testdb.datasource';
export async function givenEmptyDatabase() {
  await new ProductRepository(testdb).deleteAll();
  await new CategoryRepository(testdb).deleteAll();
}

In case a repository includes a relation to another repository, ie. Productbelongs to Category, include it in the repository call, for example:

src/tests/helpers/database.helpers.ts

import {Getter} from '@loopback/context';
import {ProductRepository, CategoryRepository} from '../../src/repositories';
import {testdb} from '../fixtures/datasources/testdb.datasource';
export async function givenEmptyDatabase() {
  let categoryRepository: CategoryRepository;
  let productRepository: ProductRepository;
  categoryRepository = new CategoryRepository(
    testdb,
    async () => productRepository,
  );
  productRepository = new ProductRepository(
    testdb,
    async () => categoryRepository,
  );
  await productRepository.deleteAll();
  await categoryRepository.deleteAll();
}

src/tests/integration/controllers/product.controller.integration.ts

// in your test file
import {givenEmptyDatabase} from '../../helpers/database.helpers';
describe('ProductController (integration)', () => {
  before(givenEmptyDatabase);
  // etc.
});

Use test data builders

To avoid duplicating code for creating model data that is complete with requiredproperties, use sharedtest data builders. This enablestests to provide the small subset of properties that is strictly required by thetested scenario. Using shared test builders will help your tests to be:

• Easier to understand, since it’s immediately clear what model properties arerelevant to the tests. If the tests set the required properties, it isdifficult to tell whether the properties are actually relevant to the testedscenario.

• Easier to maintain. As your data model evolves, you will need to add morerequired properties. If the tests build the model instance data manually, allthe tests must be manually updated to set a new required property. With ashared test data builder, you update a single location with the new property.

See@loopback/openapi-spec-builderfor an example of how to apply this design pattern for building OpenAPI Specdocuments.

In practice, a simple function that adds missing required properties issufficient.

src/tests/helpers/database.helpers.ts

// ...
export function givenProductData(data?: Partial<Product>) {
  return Object.assign(
    {
      name: 'a-product-name',
      slug: 'a-product-slug',
      price: 1,
      description: 'a-product-description',
      available: true,
    },
    data,
  );
}
export async function givenProduct(data?: Partial<Product>) {
  return new ProductRepository(testdb).create(givenProductData(data));
}
// ...

Avoid sharing the same data for multiple tests

It’s tempting to define a small set of data to be shared by all tests. Forexample, in an e-commerce application, you might pre-populate the database witha few categories, some products, an admin user and a customer. This approach hasseveral downsides:

• When trying to understand any individual test, it’s difficult to tell whatpart of the pre-populated data is essential for the test and what’sirrelevant. For example, in a test checking the method counting the number ofproducts in a category using a pre-populated category “Stationery”, is itimportant that “Stationery” contains nested sub-categories or is that factirrelevant? If it’s irrelevant, then what are the other tests that depend onit?

• As the application grows and new features are added, it’s easier to add moreproperties to existing model instances rather than create new instances usingonly the properties required by the new features. For example, when adding acategory image, it’s easier to add image to an existing category “Stationery”and perhaps keep another category “Groceries” without any image, rather thancreating two new categories “CategoryWithAnImage” and “CategoryMissingImage”.This further amplifies the previous problem, because it’s not clear that“Groceries” is the category that should be used by tests requiring a categorywith no image - the category name does not provide any hints on that.

• As the shared dataset grows (together with the application), the time requiredto bring the database into its initial state grows too. Instead of running afew “DELETE ALL” queries before each test (which is relatively fast), you mayhave to run tens or hundreds of different commands used to create differentmodel instances, thus triggering slow index rebuilds along the way and slowingdown the test suite considerably.

Use the test data builders described in the previous section to populate yourdatabase with the data specific to your test only.Write higher-level helpers to share the code for re-creating common scenarios.For example, if your application has two kinds of users (admins and customers),then you may write the following helpers to simplify writing acceptance testschecking access control:

async function givenAdminAndCustomer() {
  return {
    admin: await givenUser({role: Roles.ADMIN}),
    customer: await givenUser({role: Roles.CUSTOMER}),
  };
}

Unit testing

Unit tests are considered “white-box” tests because they use an “inside-out”approach where the tests know about the internals and control all the variablesof the system being tested. Individual units are tested in isolation and theirdependencies are replaced withTest doubles.

Use test doubles

Test doubles are functions or objects that look and behave like the realvariants used in production, but are actually simplified versions that give thetest more control of the behavior. For example, reproducing the situation wherereading from a file failed because of a hard-drive error is pretty muchimpossible. However, using a test double to simulate the file-system API willprovide control over what each call returns.

Sinon.JS has become the de-facto standard for testdoubles in Node.js and JavaScript/TypeScript in general. The @loopback/testlabpackage comes with Sinon preconfigured with TypeScript type definitions andintegrated with Should.js assertions.

There are three kinds of test doubles provided by Sinon.JS:

• Test spies are functions thatrecord arguments, the return value, the value of this, and exceptions thrown(if any) for all its calls. There are two types of spies: Some are anonymousfunctions, while others wrap methods that already exist in the system undertest.

• Test stubs are functions (spies)with pre-programmed behavior. As spies, stubs can be either anonymous, or wrapexisting functions. When wrapping an existing function with a stub, theoriginal function is not called.

• Test mocks (and mockexpectations) are fake methods (like spies) with pre-programmed behavior (likestubs) as well as pre-programmed expectations. A mock will fail your test ifit is not used as expected.

Note:

We recommend against using test mocks. With testmocks, the expectations must be defined before the tested scenario is executed,which breaks the recommended test layout ‘arrange-act-assert’ (or‘given-when-then’) and also produces code that’s difficult to comprehend.

Create a stub Repository

When writing an application that accesses data in a database, the best practiceis to use repositories to encapsulate alldata-access/persistence-related code. Other parts of the application (typicallycontrollers) can then depend on these repositories for dataaccess. To test Repository dependents (for example, Controllers) in isolation,we need to provide a test double, usually as a test stub.

In traditional object-oriented languages like Java or C#, to enable unit teststo provide a custom implementation of the repository API, the controller needsto depend on an interface describing the API, and the repository implementationneeds to implement this interface. The situation is easier in JavaScript andTypeScript. Thanks to the dynamic nature of the language, it’s possible tomock/stub entire classes.

Creating a test double for a repository class is very easy using the Sinon.JSutility function createStubInstance. It’s important to create a new stubinstance for each unit test in order to prevent unintended re-use ofpre-programmed behavior between (unrelated) tests.

describe('ProductController', () => {
  let repository: ProductRepository;
  beforeEach(givenStubbedRepository);
  // your unit tests
  function givenStubbedRepository() {
    repository = sinon.createStubInstance(ProductRepository);
  }
});

In your unit tests, you will usually want to program the behavior of stubbedmethods (what they should return) and then verify that the Controller (unitunder test) called the right method with the correct arguments.

Configure stub’s behavior at the beginning of your unit test (in the “arrange”or “given” section):

// repository.find() will return a promise that
// will be resolved with the provided array
const findStub = repository.find as sinon.SinonStub;
findStub.resolves([{id: 1, name: 'Pen'}]);

Verify how was the stubbed method executed at the end of your unit test (in the“assert” or “then” section):

// expect that repository.find() was called with the first
// argument deeply-equal to the provided object
sinon.assert.calledWithMatch(findStub, {where: {id: 1}});

See Unit test your controllers for a fullexample.

Create a stub Service

If your controller relies on service proxy for service oriented backends such asREST APIs, SOAP Web Services, or gRPC microservices, then we can create stubsfor the service akin to the steps outlined in the abovestub repository section. Consider a dependency on aGeoCoder service that relies on a remote REST API for returning coordinatesfor a specific address.

export interface GeocoderService {
  geocode(address: string): Promise<GeoPoint[]>;
}

The first step is to create a mocked instance of the GeocoderService API andconfigure its geocode method as a Sinon stub:

describe('GeocoderController', () => {
  let geoService: GeoCoderService;
  let geocode: sinon.SinonStub;
  beforeEach(givenMockGeoCoderService);
  // your unit tests
  function givenMockGeoCoderService() {
    // this creates a stub with GeocoderService API
    // in a way that allows the compiler to verify type correctness
    geoService = {geocode: sinon.stub()};
    // this creates a reference to the stubbed "geocode" method
    // because "geoService.geocode" has type from GeocoderService
    // and does not provide Sinon APIs
    geocode = geoService.geocode as sinon.SinonStub;
  }
});

Afterwards, we can configure the geocode stub’s behaviour before the actphase of our test(s):

// geoService.geocode() will return a promise that
// will be resolved with the provided array
geocode.resolves([<GeoPoint>{y: 41.109653, x: -73.72467}]);

Lastly, we’ll verify how the stub was executed:

// expect that geoService.geocode() was called with the first
// argument equal to the provided address string
sinon.assert.calledWithMatch(geocode, '1 New Orchard Road, Armonk, 10504');

Check outTodoController unit testsillustrating the above points in action for more information.

Unit test your Controllers

Unit tests should apply to the smallest piece of code possible to ensure thatother variables and state changes do not pollute the result. A typical unit testcreates a controller instance with dependencies replaced by test doubles anddirectly calls the tested method. The example below gives the controller a stubimplementation of its repository dependency using the testlabcreateStubInstance function, ensures the controller calls the repository’sfind() method with a correct query, and returns back the query results. SeeCreate a stub repository for a detailedexplanation.

src/tests/unit/controllers/product.controller.unit.ts

import {
  createStubInstance,
  expect,
  sinon,
  StubbedInstanceWithSinonAccessor,
} from '@loopback/testlab';
import {ProductRepository} from '../../../src/repositories';
import {ProductController} from '../../../src/controllers';
describe('ProductController (unit)', () => {
  let repository: StubbedInstanceWithSinonAccessor<ProductRepository>;
  beforeEach(givenStubbedRepository);
  describe('getDetails()', () => {
    it('retrieves details of a product', async () => {
      const controller = new ProductController(repository);
      repository.stubs.find.resolves([{name: 'Pen', slug: 'pen'}]);
      const details = await controller.getDetails('pen');
      expect(details).to.containEql({name: 'Pen', slug: 'pen'});
      sinon.assert.calledWithMatch(repository.stubs.find, {
        where: {slug: 'pen'},
      });
    });
  });
  function givenStubbedRepository() {
    repository = createStubInstance(ProductRepository);
  }
});

Unit test your models and repositories

In a typical LoopBack application, models and repositories rely on behaviorprovided by the framework (@loopback/repository package) and there is no needto test LoopBack’s built-in functionality. However, any additionalapplication-specific APIs do need new unit tests.

For example, if the Person Model has properties firstname, middlename andsurname and provides a function to obtain the full name, then you should writeunit tests to verify the implementation of this additional method.

Remember to use Test data builders whenever you needvalid data to create a new model instance.

src/tests/unit/models/person.model.unit.ts

import {Person} from '../../../src/models';
import {givenPersonData} from '../../helpers/database.helpers';
import {expect} from '@loopback/testlab';
describe('Person (unit)', () => {
  // we recommend to group tests by method names
  describe('getFullName()', () => {
    it('uses all three parts when present', () => {
      const person = givenPerson({
        firstname: 'Jane',
        middlename: 'Smith',
        surname: 'Brown',
      });
      const fullName = person.getFullName();
      expect(fullName).to.equal('Jane Smith Brown');
    });
    it('omits middlename when not present', () => {
      const person = givenPerson({
        firstname: 'Mark',
        surname: 'Twain',
      });
      const fullName = person.getFullName();
      expect(fullName).to.equal('Mark Twain');
    });
  });
  function givenPerson(data: Partial<Person>) {
    return new Person(givenPersonData(data));
  }
});

Writing a unit test for custom repository methods is not as straightforwardbecause CrudRepository is based on legacyloopback-datasource-jugglerwhich was not designed with dependency injection in mind. Instead, useintegration tests to verify the implementation of custom repository methods. Formore information, refer toTest your repositories against a real databasein Integration Testing.

Unit test your Sequence

While it’s possible to test a custom Sequence class in isolation, it’s better torely on acceptance-level tests in this exceptional case. The reason is that acustom Sequence class typically has many dependencies (which can make test setuplong and complex), and at the same time it provides very little functionality ontop of the injected sequence actions. Bugs are much more likely to be caused bythe way the real sequence action implementations interact together (which is notcovered by unit tests), instead of the Sequence code itself (which is the onlything covered).

See Test Sequence customizations inAcceptance Testing.

Integration testing

Integration tests are considered “white-box” tests because they use an“inside-out” approach that tests how multiple units work together or withexternal services. You can use test doubles to isolate tested units fromexternal variables/state that are not part of the tested scenario.

Test your repositories against a real database

There are two common reasons for adding repository tests:

• Your models are using an advanced configuration, for example, custom columnmappings, and you want to verify this configuration is correctly picked up bythe framework.

• Your repositories have additional methods.Integration tests are one of the places to put the best practices inData handling to work:

• Clean the database before each test

• Use test data builders
• Avoid sharing the same data for multiple testsHere is an example showing how to write an integration test for a customrepository method findByName:

src/tests/integration/repositories/category.repository.integration.ts

import {
  givenEmptyDatabase,
  givenCategory,
} from '../../helpers/database.helpers';
import {CategoryRepository} from '../../../src/repositories';
import {expect} from '@loopback/testlab';
import {testdb} from '../../fixtures/datasources/testdb.datasource';
describe('CategoryRepository (integration)', () => {
  beforeEach(givenEmptyDatabase);
  describe('findByName(name)', () => {
    it('return the correct category', async () => {
      const stationery = await givenCategory({name: 'Stationery'});
      const repository = new CategoryRepository(testdb);
      const found = await repository.findByName('Stationery');
      expect(found).to.deepEqual(stationery);
    });
  });
});

Test controllers and repositories together

Integration tests running controllers with real repositories are important toverify that the controllers use the repository API correctly, and that thecommands and queries produce expected results when executed on a real database.These tests are similar to repository tests with controllers added as anotheringredient.

src/tests/integration/controllers/product.controller.integration.ts

import {expect} from '@loopback/testlab';
import {givenEmptyDatabase, givenProduct} from '../../helpers/database.helpers';
import {ProductController} from '../../../src/controllers';
import {ProductRepository} from '../../../src/repositories';
import {testdb} from '../../fixtures/datasources/testdb.datasource';
describe('ProductController (integration)', () => {
  beforeEach(givenEmptyDatabase);
  describe('getDetails()', () => {
    it('retrieves details of the given product', async () => {
      const pencil = await givenProduct({name: 'Pencil', slug: 'pencil'});
      const controller = new ProductController(new ProductRepository(testdb));
      const details = await controller.getDetails('pencil');
      expect(details).to.containEql(pencil);
    });
  });
});

Test your Services against real backends

When integrating with other services (including our own microservices), it’simportant to verify that our client configuration is correct and the client(service proxy) API is matching the actual service implementation. Ideally,there should be at least one integration test for each endpoint (operation)consumed by the application.

To write an integration test, we need to:

• Obtain an instance of the tested service proxy. Optionally modify theconnection configuration, for example change the target URL or configure acaching proxy to speed up tests.
• Execute service proxy methods and verify that expected results were returnedby the backend service.

Obtain a Service Proxy instance

InMake service proxies easier to test,we are suggesting to leverage Providers as a tool allowing both the IoCframework and the tests to access service proxy instances.

In the integration tests, a test helper should be written to obtain an instanceof the service proxy by invoking the provider. This helper should be typicallyinvoked once before the integration test suite begins.

import {
  GeoService,
  GeoServiceProvider,
} from '../../src/services/geo.service.ts';
import {GeoDataSource} from '../../src/datasources/geo.datasource.ts';
describe('GeoService', () => {
  let service: GeoService;
  before(givenGeoService);
  // to be done: add tests here
  function givenGeoService() {
    const dataSource = new GeoDataSource();
    service = new GeoServiceProvider(dataSource).value();
  }
});

If needed, you can tweak the datasource config before creating the serviceinstance:

import {merge} from 'lodash';
import * as GEO_CODER_CONFIG from '../src/datasources/geo.datasource.json';
function givenGeoService() {
  const config = merge({}, GEO_CODER_CONFIG, {
    // your config overrides
  });
  const dataSource = new GeoDataSource(config);
  service = new GeoServiceProvider(dataSource).value();
}

Test invidivudal service methods

With the service proxy instance available, integration tests can focus onexecuting individual methods with the right set of input parameters; andverifying the outcome of those calls.

it('resolves an address to a geo point', async () => {
  const points = await service.geocode('1 New Orchard Road, Armonk, 10504');
  expect(points).to.deepEqual([
    {
      lat: 41.109653,
      lng: -73.72467,
    },
  ]);
});

Acceptance (end-to-end) testing

Automated acceptance (end-to-end) tests are considered “black-box” tests becausethey use an “outside-in” approach that is not concerned about the internals ofthe system. Acceptance tests perform the same actions (send the same HTTPrequests) as the clients and consumers of your API will do, and verify that theresults returned by the system match the expected results.

Typically, acceptance tests start the application, make HTTP requests to theserver, and verify the returned response. LoopBack usessupertest to create test code thatsimplifies both the execution of HTTP requests and the verification ofresponses. Remember to follow the best practices fromData handling when setting up your database for tests:

• Clean the database before each test
• Use test data builders
• Avoid sharing the same data for multiple tests

Validate your OpenAPI specification

The OpenAPI specification is a cornerstone of applications that provide RESTAPIs. It enables API consumers to leverage a whole ecosystem of related tooling.To make the spec useful, you must ensure it’s a valid OpenAPI Spec document,ideally in an automated way that’s an integral part of regular CI builds.LoopBack’s testlab moduleprovides a helper method validateApiSpec that builds on top of the popularswagger-parser package.

Example usage:

src/tests/acceptance/api-spec.acceptance.ts

import {HelloWorldApplication} from '../..';
import {RestServer} from '@loopback/rest';
import {validateApiSpec} from '@loopback/testlab';
describe('API specification', () => {
  it('api spec is valid', async () => {
    const app = new HelloWorldApplication();
    const server = await app.getServer(RestServer);
    const spec = server.getApiSpec();
    await validateApiSpec(spec);
  });
});

Perform an auto-generated smoke test of your REST API

Important: The top-down approach for building LoopBackapplications is not yet fully supported. Therefore, the code outlined in thissection is outdated and may not work out of the box. Check outhttps://github.com/strongloop/loopback-next/issues/1882 for the epic trackingthe feature and OpenAPI generator page for artifactgeneration from OpenAPI specs.

The formal validity of your application’s spec does not guarantee that yourimplementation is actually matching the specified behavior. To keep your spec insync with your implementation, you should use an automated tool likeDredd to run a set of smoke tests toverify your app conforms to the spec.

Automated testing tools usually require hints in your specification to tell themhow to create valid requests or what response data to expect. Dredd inparticular relies on responseexamplesand request parameterx-examplefields. Extending your API spec with examples is a good thing on its own, sincedevelopers consuming your API will find them useful too.

Here is an example showing how to run Dredd to test your API against the spec:

src/tests/acceptance/api-spec.acceptance.ts

import {expect} from '@loopback/testlab';
import {HelloWorldApplication} from '../..';
import {RestServer, RestBindings} from '@loopback/rest';
import {spec} from '../../apidefs/openapi';
const Dredd = require('dredd');
describe('API (acceptance)', () => {
  let app: HelloWorldApplication;
  /* eslint-disable @typescript-eslint/no-explicit-any */
  let dredd: any;
  before(initEnvironment);
  after(async () => {
    await app.stop();
  });
  it('conforms to the specification', done => {
    dredd.run((err: Error, stats: object) => {
      if (err) return done(err);
      expect(stats).to.containDeep({
        failures: 0,
        errors: 0,
        skipped: 0,
      });
      done();
    });
  });
  async function initEnvironment() {
    app = new HelloWorldApplication();
    const server = await app.getServer(RestServer);
    // For testing, we'll let the OS pick an available port by setting
    // RestBindings.PORT to 0.
    server.bind(RestBindings.PORT).to(0);
    // app.start() starts up the HTTP server and binds the acquired port
    // number to RestBindings.PORT.
    await app.boot();
    await app.start();
    // Get the real port number.
    const port = await server.get(RestBindings.PORT);
    const baseUrl = `http://localhost:${port}`;
    const config: object = {
      server: baseUrl, // base path to the end points
      options: {
        level: 'fail', // report 'fail' case only
        silent: false, // false for helpful debugging info
        path: [`${baseUrl}/openapi.json`], // to download apiSpec from the service
      },
    };
    dredd = new Dredd(config);
  }
});

The user experience needs improvement and we are looking into better solutions.See GitHub issue #644.Let us know if you have any recommendations!

Test your individual REST API endpoints

You should have at least one acceptance (end-to-end) test for each of your RESTAPI endpoints. Consider adding more tests if your endpoint depends on (custom)sequence actions to modify the behavior when the corresponding controller methodis invoked via REST, compared to behavior observed when the controller method isinvoked directly via JavaScript/TypeScript API. For example, if your endpointreturns different responses to regular users and to admin users, then you shouldtwo tests (one test for each user role).

Here is an example of an acceptance test:

src/tests/acceptance/product.acceptance.ts

import {HelloWorldApplication} from '../..';
import {Client, createRestAppClient, expect} from '@loopback/testlab';
import {givenEmptyDatabase, givenProduct} from '../helpers/database.helpers';
import {RestServer, RestBindings} from '@loopback/rest';
import {testdb} from '../fixtures/datasources/testdb.datasource';
describe('Product (acceptance)', () => {
  let app: HelloWorldApplication;
  let client: Client;
  before(givenEmptyDatabase);
  before(givenRunningApp);
  after(async () => {
    await app.stop();
  });
  it('retrieves product details', async () => {
    // arrange
    const product = await givenProduct({
      name: 'Ink Pen',
      slug: 'ink-pen',
      price: 1,
      category: 'Stationery',
      description: 'The ultimate ink-powered pen for daily writing',
      label: 'popular',
      available: true,
      endDate: null,
    });
    const expected = Object.assign({id: product.id}, product);
    // act
    const response = await client.get('/product/ink-pen');
    // assert
    expect(response.body).to.containEql(expected);
  });
  async function givenRunningApp() {
    app = new HelloWorldApplication({
      rest: {
        port: 0,
      },
    });
    app.dataSource(testdb);
    await app.boot();
    await app.start();
    client = createRestAppClient(app);
  }
});

Test Sequence customizations

Custom sequence behavior is best tested by observing changes in behavior of theaffected endpoints. For example, if your sequence has an authentication stepthat rejects anonymous requests for certain endpoints, then you can write a testmaking an anonymous request to those endpoints to verify that it’s correctlyrejected. These tests are essentially the same as the tests verifyingimplementation of individual endpoints as described in the previous section.