September 4, 2019

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: 

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:


Happy Testing!


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

Twitter | YouTubeLinkedIn | Articles

1 comment:

for ict 99 said...

The effectiveness of IEEE Project Domains depends very much on the situation in which they are applied. In order to further improve IEEE Final Year Project Domains practices we need to explicitly describe and utilise our knowledge about software domains of software engineering Final Year Project Domains for CSE technologies. This paper suggests a modelling formalism for supporting systematic reuse of software engineering technologies during planning of software projects and improvement programmes in Final Year Projects for CSE.

Software management seeks for decision support to identify technologies like JavaScript that meet best the goals and characteristics of a software project or improvement programme. JavaScript Training in Chennai Accessible experiences and repositories that effectively guide that technology selection are still lacking.

Aim of technology domain analysis is to describe the class of context situations (e.g., kinds of JavaScript software projects) in which a software engineering technology JavaScript Training in Chennai can be applied successfully

The Angular Training covers a wide range of topics including Components, Angular Directives, Angular Services, Pipes, security fundamentals, Routing, and Angular programmability. The new Angular TRaining will lay the foundation you need to specialise in Single Page Application developer. Angular Training