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
  • Which Actions to implement?
  • Test Interface Action Implementation Guidelines
  • 1. Switch Statement
  • 2. Test Interface Actions must use same code pathways as real-life counterparts
Edit on GitHub
  1. Open Booking API
  2. Testing booking
  3. Implementing the Test Interface

Test Interface Actions

PreviousImplementing the Test InterfaceNextCreate Opportunity Endpoint

Last updated 1 year ago

The is called by to simulate different actions in your booking system e.g. "Seller-requested cancellation".

Your booking system only need to implement those actions which relate to that it implements.

Descriptions for each action can be found in the .

Which Actions to implement?

Use to find out which Test Interface actions your booking system needs to implement. Follow these steps:

  1. In your Test Suite instance, , run:

# Use your config/dev.json config file
export NODE_ENV=dev
# Run Test Data Generator
npm run test-data-generator
  1. The logs from this script will point to two files that it generated, called:

    • opportunity-test-data.json

    • test-interface-actions.json

  2. The test-interface-actions.json file will contain a list of Test Interface actions that you need to implement for the features that your booking system supports. To see an example of what this looks like, see the .

Test Interface Action Implementation Guidelines

1. Switch Statement

Use something like a switch statement for your actions endpoint. For example, if your booking system only needs to support the test:SellerRequestedCancellationSimulateAction and test:CustomerNoticeSimulateAction actions, your route would look like (using Node.js with Express as an example):

app.post('/test-interface/actions', (req, res) => {
  const actionType = req.body['@type'];
  switch (actionType) {
    case 'test:SellerRequestedCancellationSimulateAction':
      simulateSellerRequestedCancellation(req, res);
      break;
    case 'test:CustomerNoticeSimulateAction':
      simulateCustomerNotice(req, res);
      break;
    default:
      res.sendStatus(404);
      break;
    }
});

2. Test Interface Actions must use same code pathways as real-life counterparts

As an example, when implementing the test:SellerRequestedCancellationSimulateAction Test Interface action, the test logic should use, as much as possible, the same code pathways as are called when an administrator cancels an activity in the real system. The goal is to replicate real-world processes accurately, rather than simply employing quick fixes to meet Test Suite expectations.

Here is a very simplified example of the correct way to do this (using Node.js with Express):

app.get('/internal-admin-api/dashboard', (req, res) => {
  res.send(`<form action="cancel-order" method="POST">
    <label for="orderId">Cancel Order with ID:</label>
    <input type="text" id="orderId" name="orderId" required />
    <input type="submit" value="Cancel" />
  </form>`);
});

app.post('/internal-admin-api/cancel-order', async (req, res) => {
  await cancelOrderAndUpdateOrdersFeeds(req.body.orderId);
  res.send('Successfully cancelled!');
});

app.post('/test-interface/actions', (req, res) => {
  const actionType = req.body['@type'];
  switch (actionType) {
    case 'test:SellerRequestedCancellationSimulateAction':
      await cancelOrderAndUpdateOrdersFeeds(req.body.object['@id']);
      res.sendStatus(204);
      break;
    // ... other actions
  }

async function cancelOrderAndUpdateOrdersFeeds(orderId) {
  // ...
}

This approach is key to ensuring that Test Suite accurately verifies all of the booking system's behaviours that will occur in real-life operation.

Test Interface Actions endpoint
Test Suite
Test Interface doc
Test Data Generator
which you configured in the previous step
Test Data Generator README
features