-
Notifications
You must be signed in to change notification settings - Fork 1
How‐to: Eagle1 whereis API testing
The tests folder in the project contains a comprehensive suite of unit and integration tests designed to ensure the reliability and correctness of various components of the API. These tests cover different aspects of the system, including token retrieval, event fetching, route retrieval, and API endpoint functionality for multiple carriers such as FedEx and SF Express.
- Unit Testing: Individual components and methods are tested in isolation (e.g., token retrieval, event fetching).
- Integration Testing: API endpoints are tested to ensure proper interaction between different parts of the system.
- Parameterized Testing: Tests use predefined test data to cover various scenarios and edge cases.
- Error Handling: Tests include cases to verify proper error handling and reporting.
- Cross-carrier Testing: The test suite covers multiple carriers (FedEx and SF Express) to ensure compatibility and consistency.
The modular structure of the tests allows for easy maintenance and expansion as new features are added to the API.
- main_test.ts
- get_fdx_token_test.ts
- get_fdx_events_test.ts
- get_sfex_routes_test.ts
- whereis_api_test.ts
- status_api_test.ts
- Test Data: Defines the input data required for the current test and the expected output results.
- Test Code: Reads the input test data, calls the API to obtain the return value, and compares it with the expected output defined in the test data.
The tests use a configuration file (config_dev.json) to set up the testing environment. This file contains:
{
"server": {
"protocol": "http",
"host": "localhost",
"port": 8080
},
"bearerToken": "Your-Token"
}This configuration specifies the server details and authentication token used for testing.
This file serves as the entry point for the test suite. It includes the following key features:
- Loads environment variables and metadata required for testing. (
initTestConfig) - Handles command-line arguments to specify different test configuration files.
- Imports and runs all other test files.
This file tests the FedEx API token retrieval functionality:
- Tests the
Fdx.getToken()method. - Verifies that a valid authentication token is retrieved from the FedEx API.
- Checks if the returned token has the expected length.
This file contains unit tests for retrieving FedEx shipment tracking events:
- Tests the
Fdx.getRoute()method. - Verifies that the correct number of scan events are retrieved for a given tracking number.
- Uses predefined test data, including a sample tracking number and expected event count.
This file tests the retrieval of SF Express shipment tracking routes:
- Tests the
Sfex.getRoute()method. - Verifies that the correct number of route events are retrieved for a given tracking number and phone number.
- Uses predefined test data and accounts for potential limitations with completed waybills.
This file contains integration tests for the "whereis" API endpoint:
- Tests the
/v0/whereis/{trackingId}endpoint. - Verifies the API's ability to retrieve tracking information for various carriers, including SF Express.
- Checks if the API returns the expected number of tracking events for each test case.
- Includes tests for completed waybills to demonstrate handling of historical data limitations.
This file contains integration tests for the "status" API endpoint:
- Tests the
/v0/status/{trackingId}endpoint. - Verifies the API's ability to retrieve the current status of shipments for various carriers.
- Includes test cases for both SF Express and FedEx shipments.
- Checks for correct error codes and status codes in different scenarios.
Tests can be run using the Deno test runner. The main_test.ts file serves as the entry point.
To run the tests, use the following command:
deno test --allow-net --allow-read --allow-env tests/main_test.tsThe test runner loads config_dev.json from the tests folder by default. Ensure this file is present in the tests directory before running the tests.
You can also specify a different configuration file using command-line arguments:
deno test --allow-net --allow-read --allow-env tests/main_test.ts custom_config.jsonThe current test results heavily rely on the data provided by external data providers. For the same trackingId, due to reasons on the data provider's side, the data obtained at different times may vary. Therefore, if the test results are inconsistent with the expected results during testing, the first step is to confirm whether this is due to changes in the data source.
(C) 2025 Eagle1