Are you sure the buses are still listed? Setting up data-driven API tests with Ruby + NET::HTTP + Gauge

The Massachusetts Bay Transit Authority (MBTA) operates a series of bus lines, whose information is accessible through their API, https://api-v3.mbta.com/. How could you test that a sampling of these bus lines are still listed?

• Route 210  | Quincy Center - Fields Corner           
• Route 212  | Quincy Center - North Quincy           
• Route 220  | Hingham Depot - Quincy Center         
• Route 222  | East Weymouth - Quincy Center         
• Route 230  | Montello Commuter Rail Station - Quincy   
• Route 236  | South Shore Plaza - Quincy Center

Sure, you could go to the MBTA website and search for the bus route at https://www.mbta.com/schedules/bus but, as we saw in our project Are You Sure The Bus Line Is Still Listed?, what is best for humans is not best when creating an automated test. 

With this project, we are going to use the built-in Ruby Library NET::HTTP to interact with the API, and Thoughtworks Gauge to set up the test framework, and we are going to make the tests data-driven, putting the information we need to verify in a table.

Related Documentation: 

• Documentation for the MBTA API  V3 is at https://www.mbta.com/developers/v3-api
• MBTA V3 API Developer Portal: https://api-v3.mbta.com

Exploring the API

Let's say we wanted to verify that the MBTA bus route 230 was listed, with the name, "Montello Commuter Rail Station - Quincy Center". If we go to https://api-v3.mbta.com/routes/230/ we can get the following information in a JSON format:

 {  
  "data": {  
   "attributes": {  
    "color": "FFC72C",  
    "description": "Local Bus",  
    "direction_destinations": [  
     "Montello Commuter Rail Station",  
     "Quincy Center"  
    ],  
    "direction_names": [  
     "Outbound",  
     "Inbound"  
    ],  
    "fare_class": "Local Bus",  
    "long_name": "Montello Commuter Rail Station - Quincy Center",  
    "short_name": "230",  
    "sort_order": 52300,  
    "text_color": "000000",  
    "type": 3  
   },  
   "id": "230",  
   "links": {  
    "self": "\/routes\/230"  
   },  
   "relationships": {  
    "line": {  
     "data": {  
      "id": "line-230",  
      "type": "line"  
     }  
    },  
    "route_patterns": {  
    }  
   },  
   "type": "route"  
  },  
  "jsonapi": {  
   "version": "1.0"  
  }  
 }  

We can see that under "data" and "attributes", the field that will help us is "long_name".  As a test we can:

• Get the route name we want to test, and the long_name that we expect to appear. 
• Pass the route to the ROUTES api. Make sure that the expected and actual values match up. 

Setting Up The Project

The test framework I created can be found on my GitHub site at https://github.com/tjmaher/gauge-ruby-api.

How did I create it?

On my MacBook, I first created a directory to hold the project, moved into that directory, updated the MacOS package manager HomeBrew, installed Gauge, initialized a new Gauge project in Ruby, and ran the Gauge sample test project that was installed:

• mkdir gauge-ruby-api
• cd gauge-ruby-api
• brew update
• brew install gauge
• gauge init ruby
• bundle exec gauge run specs

After I saw that the demo project the Gauge initialization installed had passed, I could then write a testplan and place it in the /spec folder.

Writing the Specification For The Test

Let's say we want to take the six routes we want to test, and put it in a table that we can then feed to a test scenario. We can replace what is in the spec folder of our sample project with one called routes_long_name.spec:

 # ROUTE: Verify that the Long Name is Returned  
   
 Given the ID, verify that the route api returns the  
 long_name of the route.  
   
 |route| long_name                         |  
 |-----------------------------------------|  
 | 210 | Quincy Center - Fields Corner     |  
 | 212 | Quincy Center - North Quincy      |  
 | 220 | Hingham Depot - Quincy Center     |  
 | 222 | East Weymouth - Quincy Center     |  
 | 230 | Montello Commuter Rail Station - Quincy Center |  
 | 236 | South Shore Plaza - Quincy Center |  
   
 ## Given the route id return the long_name  
 * Passing <route> to ROUTES api returns <long_name>  

The Thoughtworks Gauge framework allows data-driven execution. Row by row, what is in the route column and the long_name column will fed to the test scenario and executed. Instead of writing six separate test scenarios, we can write only one, switching up the data.

Once we have test scenarios written this way, adding more tests is as simple as adding another row of test data.

Now that we have our tests set up, with the next section we will build out how to interact with the API using Ruby and the Net/HTTP library in Gauge's step implementation.

Are you sure the buses are still listed? 
Data-driven API tests with Ruby + NET::HTTP + ThoughtWorks Gauge:

• Part One: Setting up the test plan and table data in a spec file
• Part Two: Interacting with the MBTA API using NET::HTTP
• Source Code: https://github.com/tjmaher/gauge-ruby-api

Happy Testing!


-T.J. Maher
Sr. QA Engineer, Software Engineer in Test
Meetup Organizer, Ministry of Testing - Boston

Twitter | YouTube | LinkedIn | Articles