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
  • Controlled Mode
  • Random Mode
Edit on GitHub
  1. Open Booking API
  2. Testing booking

Implementing the Test Interface

PreviousConfiguring Test SuiteNextTest Interface Actions

Last updated 1 year ago

Some subset of the needs to be implemented in order to finally .

Which parts ot the Test Interface need to be implemented depends on .

Controlled Mode

In order to use Controlled mode, more of the Test Interface needs to be implemented. But the trade off is that testing is much easier and more reliable. This is the recommended choice.

When using Controlled mode, the following parts of Test Interface need to be implemented in your booking system:

  • Datasets Endpoints ( — see for more details):

    • These endpoints are called by to create test opportunity data in your booking system, and – later – to clean up that test opportunity data.

    • See the

  • Actions Endpoints ():

    • This endpoint is called by to simulate different kinds of booking actions, like an update to a booking's access pass.

    • See the .

Random Mode

In order to use Random mode, less of the Test Interface needs to be implemented. But the trade off is that it is more difficult to do reliable and consistent testing. Therefore, the recommended choice is to use .

When using Random mode, the following parts of Test Interface need to be implemented in your booking system:

  • Actions Endpoints ():

    • This endpoint is called by to simulate different kinds of booking actions, like an update to a booking's access pass.

    • See the .

Test Interface
test your booking system
spec
Test Suite
spec
Test Suite
Actions page for details on what to implement
spec
Test Suite
Actions page for details on what to implement
Controlled mode
your choice of Controlled mode or Random mode