API Endpoint Testing
Relevant source files
The following files were used as context for generating this wiki page:
API Endpoint Testing in the Spotify API Data Collector project ensures the reliability, performance, and correctness of the FastAPI-based web service. These tests validate the endpoints responsible for exposing collected Spotify metadata, including track listings, artist-specific queries, and aggregate statistics. The testing suite utilizes pytest and FastAPI.testclient to simulate HTTP requests and verify JSON responses against expected data structures.
Sources: test/test_api.py:1-15, app/api.py:1-15
Testing Infrastructure and Architecture
The testing architecture relies on a modular setup where database initialization is handled via pytest fixtures. This ensures that every test run starts with a known state, either by initializing a temporary SQLite database or by mocking a CSV data source.
Test Client Configuration
A central client fixture is used to instantiate the TestClient(app), which triggers the FastAPI startup events, including database initialization through init_db().
The diagram above illustrates the flow of a typical API test case from fixture setup to final response assertion.
Sources: test/test_api.py:19-27, test/test_api_extended.py:11-20
Functional Endpoint Coverage
The test suite provides comprehensive coverage for all primary endpoints defined in app/api.py. These tests verify HTTP status codes, response schemas, and filtering logic.
Core Endpoints and Test Cases
| Endpoint | Method | Key Test Focus | Source File |
|---|---|---|---|
/ | GET | Root metadata and versioning | test/test_api.py:84-93 |
/tracks | GET | Pagination (limit/offset), Year filter, Popularity filter | test/test_api.py:96-140 |
/tracks/year/{year} | GET | Path parameter validation (2020-2024 range) | test/test_api.py:143-169 |
/tracks/artist/{name} | GET | Case-insensitive search, partial matching | test/test_api.py:172-225 |
/stats | GET | Aggregation logic, handling empty datasets | test/test_api.py:228-258 |
/health | GET | Service availability check | test/test_api.py:261-270 |
Sources: app/api.py:48-185, test/test_api.py:84-270
Filtering and Pagination Logic
Extended tests verify that the API correctly handles complex query combinations. For example, tests ensure that limit and offset parameters correctly slice the result set returned from the database.
Data Persistence and Mocking
The project supports testing against two data sources: a live-initialized SQLite database and a mock CSV file (spotify_data.csv).
CSV Data Mocking
Tests use a sample_csv_file fixture to create a temporary CSV file with controlled data. This is crucial for verifying that the API gracefully handles file-based data retrieval when the database is not the primary source or when testing specific data parsing scenarios.
Database Interaction Testing
Tests in test_database.py and test_api_extended.py focus on the interaction between API logic and the SQLite layer. These tests verify:
- Idempotence: Ensuring duplicate tracks (checked by
track_id) are not inserted. - Index Performance: Verification through search tests by artist and year.
- CRUD Operations: Batch insertions and single track lookups.
Sources: test/test_api.py:30-81, test/test_database.py:75-92, app/api.py:21-30
Startup and Lifecycle Testing
The API lifecycle includes a startup event that triggers init_db(db). This is verified in test_api_extended.py to ensure that the tables (tracks) and indexes (idx_year, idx_artist_name) are created before any requests are processed.
Conclusion
API Endpoint Testing in this project ensures that the data collection pipeline effectively exposes its results. By combining unit tests for database functions with integration tests for FastAPI endpoints, the suite guarantees that filters for popularity, year, and artist are applied correctly and that the system remains resilient even when no data has been collected yet.
Sources: test/test_api.py:246-258, README.md:143-160