OpenActive Developers
Data ValidatorDataset DashboardW3C Community Group
  • Welcome to our community
  • Publishing Data
    • Data Feeds
      • How an RPDE data feed works
      • Types of RDPE feed
      • Implementing RPDE
      • Testing RPDE feeds
      • Scaling RPDE feeds
    • Activity list references
    • Including geo coordinates
    • Schedules
    • Dataset Sites
    • Virtual Events
    • On-Demand Events
    • Opening Hours
    • Data Quality
  • Using data
    • Harvesting opportunity data
      • Large Integers in JavaScript
    • Tutorial: Consuming an RPDE feed
    • Attribution
  • Open Booking API
    • Key Decisions
    • Implementing booking
    • Testing booking
      • Configuring Test Suite
      • Implementing the Test Interface
        • Test Interface Actions
        • Create Opportunity Endpoint
      • Random Mode: Generating Test Opportunity Data
      • Running Test Suite
      • Generating the Conformance Certificate
  • Data Model
    • Data Model Overview
    • @context and JSON-LD
    • Types Reference
      • Action
      • AudioObject
      • BabyChanging
      • Barcode
      • BookingService
      • BooleanFormFieldSpecification
      • Brand
      • ChangingFacilities
      • ConceptScheme
      • Concept
      • CourseInstance
      • Course
      • Creche
      • CustomerAccount
      • DataCatalog
      • DataDownload
      • Dataset
      • DropdownFormFieldSpecification
      • DynamicPayment
      • Entitlement
      • EventSeries
      • Event
      • FacilityUse
      • FileUploadFormFieldSpecification
      • GeoCoordinates
      • HeadlineEvent
      • ImageObject
      • IndividualFacilityUse
      • InternalApplicationError
      • InternalLibraryConfigurationError
      • InternalLibraryError
      • Lease
      • LocationFeatureSpecification
      • Lockers
      • MediaObject
      • OfferOverride
      • Offer
      • OnDemandEvent
      • OpenBookingError
      • OpeningHoursSpecification
      • OrderItem
      • OrderProposal
      • OrderQuote
      • Order
      • Organization
      • ParagraphFormFieldSpecification
      • Parking
      • PartialSchedule
      • Payment
      • Person
      • Place
      • PostalAddress
      • PriceSpecification
      • PrivacyPolicy
      • PropertyValueSpecification
      • PropertyValue
      • QuantitativeValue
      • Schedule
      • ScheduledSession
      • SessionSeries
      • ShortAnswerFormFieldSpecification
      • Showers
      • Slot
      • SportsActivityLocation
      • TaxChargeSpecification
      • TermsOfUse
      • Terms
      • Toilets
      • Towels
      • VideoObject
      • VirtualLocation
      • WebAPI
  • Specifications
    • Specifications Overview
  • Useful links
    • Data Visualiser
    • Data Validator
    • Dataset Dashboard
    • Non-technical Guidance
  • OpenActive on GitHub
    • Overview
    • Activity List
    • Community
    • Controlled Vocabularies
    • Dataset Publication
    • Documentation
    • Implementation Support
    • Programmes
    • RPDE
    • SKOS
    • Specifications
    • Validators
Powered by GitBook
On this page
  • Step 1: Install the test suite
  • Step 2: Create a local configuration file
  • Step 3: Configure flows
  • Step 4: Configure features
  • Step 5: Configure Opportunity Types
  • Step 6: Configure Controlled vs Random testing mode
  • Random mode
  • Controlled mode
  • Step 7: Configure Sellers and Booking Authentication
  • Step 8: Configure Orders Feed Authentication
  • Step 9: Configure Dataset Site
Edit on GitHub
  1. Open Booking API
  2. Testing booking

Configuring Test Suite

PreviousTesting bookingNextImplementing the Test Interface

Last updated 1 year ago

Step 1: Install the test suite

Clone the test suite repository locally, and install its dependencies.

version 14 or above is required ().

git clone git@github.com:openactive/openactive-test-suite.git
cd openactive-test-suite
npm install

You can check that the test suite works in your local environment by running it against the hosted , simply by using the default configuration:

npm start -- core

Note that the above command only runs the "core" tests within the test suite, which should take around 60 seconds to complete.

The hosted is running on a basic developer tier Azure instance with a burst quota, so if the application shuts down, simply wait 5 minutes and try again.

The quota is sufficient for the most common use cases: running a small subset of tests or individual tests against the reference implementation.

This quota is insufficient for running all tests in the test suite at once. If you are interested in viewing the results of all tests passing against the reference implementation, the results are published for both and mode.

Step 2: Create a local configuration file

Copy the file ./config/default.json to ./config/dev.json and configure it to point to the local development environment of your own booking system using the steps on the rest of this page.

Set the environment variable NODE_ENV to dev to instruct the test suite to use dev.json file to override each of the values in default.json:

export NODE_ENV=dev
npm start -- core
set NODE_ENV=dev
npm start -- core

Step 3: Configure flows

The Open Booking API includes two flows:

./config/dev.json (extract)
"integrationTests": {  
  ...
  "bookingFlowsInScope": {
    "OpenBookingSimpleFlow": true,
    "OpenBookingApprovalFlow": true
  },
  ...
}

Step 4: Configure features

Before you start your implementation, it is good to configure your config file to match your aspirations. You can then use different test suite commands to run only a subset of the tests during development, and then run npm start to run all tests.

./config/dev.json (extract)
"integrationTests": {  
  ...
  "implementedFeatures": {
    "opportunity-feed": true,
    "dataset-site": true,
    "availability-check": true,
    ...
  }
  ...
}

Step 5: Configure Opportunity Types

./config/dev.json (extract)
"integrationTests": {  
  ...
  "bookableOpportunityTypesInScope": {
    "ScheduledSession": true,
    "FacilityUseSlot": false,
    "IndividualFacilityUseSlot": false,
    "CourseInstance": false,
    "CourseInstanceSubEvent": false,
    "HeadlineEvent": false,
    "HeadlineEventSubEvent": false,
    "Event": false,
    "OnDemandEvent": false
  },
  ...
}

Step 6: Configure Controlled vs Random testing mode

Random mode

./config/dev.json (extract)
"integrationTests": {  
  ...
  "useRandomOpportunities": true
  ...
}

Controlled mode

./config/dev.json (extract)
"integrationTests": {  
  ...
  "useRandomOpportunities": false
  ...
}

Step 7: Configure Sellers and Booking Authentication

The test suite will making all bookings under a specific primary Seller provided in the configuration, using the authentication request headers provided for that Seller.

./config/dev.json (extract)
"sellers": {
  "primary": {
    "@type": "Organization",
    "@id": "https://localhost:5001/api/identifiers/sellers/1",
    "authentication": {
      "loginCredentials": null,
      "requestHeaders": {
        "X-OpenActive-Test-Client-Id": "test",
        "X-OpenActive-Test-Seller-Id": "https://localhost:5001/api/identifiers/sellers/1"
      }
    }
  },
  "secondary": {
    "@type": "Organization",
    "@id": "https://localhost:5001/api/identifiers/sellers/2",
    "authentication": {
      "loginCredentials": null,
      "requestHeaders": {
        "X-OpenActive-Test-Client-Id": "test",
        "X-OpenActive-Test-Seller-Id": "https://localhost:5001/api/identifiers/sellers/2"
      }
    }
  }
}

Step 8: Configure Orders Feed Authentication

Configure the broker microservice with the authentication headers required for the Orders Feed.

./config/dev.json (extract)
"broker": {
  ...
  "bookingPartners": {
    "primary": {
      "authentication": {
        "initialAccessToken": null,
        "ordersFeedRequestHeaders": {
          "X-OpenActive-Test-Client-Id": "test"
        }
      }
    },
    "secondary": null
  }
  ...
}

Step 9: Configure Dataset Site

./config/dev.json (extract)
"broker": {
  ...
  "datasetSiteUrl": "https://reference-implementation.openactive.io/openactive"
  ...
}

Adding other ./config/{NODE_ENV}.json files allows you to override the default configuration. For more information see this .

Assess whether or not your implementation will include either or both of these flows, and configure the test suite accordingly, as detailed in the , for example:

Ensure that your configuration of implementedFeatures matches the list of features that you have decided upon in . This configuration property is documented in the .

The list of Open Booking API features supported by the test suite can be found in the page.

Note that not all Open Booking API features are currently supported by the test suite. For a list of supported features, please see the page.

Set up the Opportunity Types that your booking system will support, as detailed in the . The test suite will only attempt to book opportunity types that are configured here, for example:

Configure Test Suite to use the testing mode that you have chosen from . You can always start with one and switch to the other later.

For more details, see (Key Decisions).

For more details, see (Key Decisions).

If your booking system only supports a single seller, only the “primary” seller is required. If your booking system supports multiple sellers, the “secondary” seller must also be set to support the “” tests.

Your configuration should match your decision in (Key Decisions).

See the for more information.

Your configuration should match your decision in (Key Decisions).

Note such authentication .

The datasetSiteUrl must be set to the local dataset site URL of your booking system. If you have not yet implemented a dataset site, details for creating it can be found .

In addition to the standard dataset site, the JSON-LD of the page must include the accessService property, as specified in the . Note that the endpointURL within the accessService is most important, and must refer to your local Open Booking API .

Node.js
which version am I using?
OpenActive Reference Implementation
OpenActive Reference Implementation
random
controlled
documentation
Simple Booking Flow
Booking Flow with Approval
reference documentation
Test Suite Feature Coverage
Test Suite Feature Coverage
reference documentation
multiple-sellers
reference documentation
must not be specific to any particular seller
here
reference documentation
Base URI
reference documentation
Which Features?
Controlled Mode or Random Mode?
#random-mode
#controlled-mode
Authentication Model?
Authentication Model?