Create an API to query forecast data

[amehta-scottlogic]

Acceptance Criteria

• An API exists with details: GET /air-pollutant/forecast
• Required query parameters should be valid_time_from, valid_time_to, location_type, base_time
• Optional query parameters should be location_name

• Response should be JSON array with following fields in each document:	Field	Value from database
  base_time	forecast_base_time
  valid_time	forecast_valid_time
  location_type	location_type
  location_name	name
  overall_aqi_level	overall_aqi_level
  no2	no2 object
  o3	o3 object
  pm2_5	pm2_5 object
  pm10	pm10 object
  so2	so2 object

  Input	Format
  valid_time_from	YYYY-MM-DDThh:mm:ss.sssZ
  valid_time_to	YYYY-MM-DDThh:mm:ss.sssZ
  base_time	YYYY-MM-DDThh:mm:ss.sssZ
  location_type	string, all lower case
  location_name	string, capital letter at beginning

For this ticket to be done it must include automation

Test Checklist:

• [x] Test Analysis & discussion with developer
• [x] Write Test Cases / Charters
• [x] Test Cases & Charters Reviewed
• [x] Test Cases Executed
• [x] Test Charters Executed
• [x] Regression tests executed
• [x] Automation Tests added to project

[mwalker-scottlogic]

Regression tests executed 05/06

[mwalker-scottlogic]

Test Analysis

• From talking to @Ben-EJ , expected 200 status for success, 422 if location type is invalid, and everything else is handled by FastAPI
• Undertake an initial sense check using Postman
• Create automation using Pytest with Request library for functional test cases
• POISED testing heuristic applied
• Load testing TBC

Parameters:

• Verify valid_time_from, valid_time_to, location_type & base_time are required parameters
  • Expect happy path response with all required parameters being valid and there being corresponding data in the database
  • Expect unhappy path response with permutations of required parameters being:
  • invalid --> use charter for different ways this can be invalid
  • missing
  • empty
  • null
  • Expect unhappy path response with all required parameters being valid and optional parameter being
  • invalid --> use charter for different ways this can be invalid
  • empty
  • null
• Verify location_name is an optional parameter
  • Expect happy path response with all required parameters & the optional parameter being valid and there being corresponding data in the database
• Boundary value analysis on parameters

Output:

• Verify happy path response matches JSON schema
• Verify unhappy path matches schema -->what is the unhappy path schema? Exploratory testing revealed sensible messages are displayed for incorrect inputs
• Verify a successful request is status 200
• Verify invalid location_type is status 422
• Verify other unhappy paths have a sensible status code
• Headers?
• Logging?

Interoperability:

Security:

Errors:

• No unhandled exceptions
• Error info
• Verify behaviour if database is down

Data:

• Verify it can return correct data from small dataset --> use charter to explore
• Verify that it can return correct data from large dataset --> use charter to explore
• Verify performance with database size --> use charter to explore

Test Charter:

• Explore forecast data API with permutations of required and optional parameters and sequencing to discover if this is working as expected This is now automated
• Explore forecast data API with different inputs to discover input validity :white_check_mark:
• Explore forecast data API using different sized databases to discover performance and accuracy

Regression candidate:

• Yes

[mwalker-scottlogic]

FINDING - valid_date_to doesn't seem to include the upper bound

Steps to reproduce:

• Postman GET request to air-pollutant/forecast endpoint with
  • forecast_base_time set to a datetime that overlaps with data in your forecast_data database e.g 2024-06-06T00%3A00%3A00.000%2B00%3A00
  • valid_date_from set to the same as forecast_base_time
  • valid_date_to set to the top end of the expected forecast eg 2024-06-11T00%3A00%3A00.000%2B00%3A00
  • location_type = city
  • location_name set to a city in the locations database
• search the response for the city name
• query the mongo database for the forecast base time and city
• compare the number of items

Expected:

• Same number of items (41)

Actual

• One less in the API response, the missing data being the upper bound of the date range

Retested

fixed

[mwalker-scottlogic]

Finding

• the AC for this ticket has a valid_time key, but we have implemented valid_date

Steps to reproduce:

• Look in the forecast_data database, observe the valid_date key

[mwalker-scottlogic]

Findings

• Discoveries from exploratory testing (see notes)
• valid_date_from, valid_date_to, forecast_base_time can all take numbers as parameter values, including negative numbers, with a 200 status

• using a year of 0000 in the datetime gets a 500 error for all date parameters

• location_name does not seem to have any kind of validation, you can use for example <>, /, - returning an empty array with status 200
• you can send a body, I was able to send a json and a 10 paragraph string
• it works with no headers
• I dropped the collection in MongoDB, I got back an empty array and a 200 response

[mwalker-scottlogic]

Finding

Required query param names are not all correct:

• should be valid_time_from, valid_time_to, location_type, base_time
• actually are valid_date_from, valid_date_to, location_type, forecast_base_time

[amehta-scottlogic]

Findings

• Discoveries from exploratory testing (see notes)
• valid_date_from, valid_date_to, forecast_base_time can all take numbers as parameter values, including negative numbers, with a 200 status

• using a year of 0000 in the datetime gets a 500 error for all date parameters

• location_name does not seem to have any kind of validation, you can use for example <>, /, - returning an empty array with status 200
• you can send a body, I was able to send a json and a 10 paragraph string
• it works with no headers
• I dropped the collection in MongoDB, I got back an empty array and a 200 response

My opinion on findings:

• numbers as parameter values for dates - no change needed
• year of 0000 - no change needed
• location_name validation - no change needed
• sending a body - no change needed
• no headers - no change needed
• dropped collection - no change needed

[amehta-scottlogic]

Finding

Required query param names are not all correct:

• should be valid_time_from, valid_time_to, location_type, base_time
• actually are valid_date_from, valid_date_to, location_type, forecast_base_time

Agreed with this - will make changes

[amehta-scottlogic]

Finding

• the AC for this ticket has a valid_time key, but we have implemented valid_date

Steps to reproduce:

• Look in the forecast_data database, observe the valid_date key

Also should be fixed

[mwalker-scottlogic]

• forecast_api_seeded_data_tests.py tests now passing
• forecast_api_validation_tests.py tests now passing