- 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
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
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:
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
2 comments:
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
It is very nice information about the digital marketing.Thanks for sharing with us.
Software testing course
Post a Comment