Problem
The round-trip search tests in tests/search/test_search_flights.py make real HTTP requests to the Google Flights API. Round-trip searches are especially slow because they make multiple sequential API calls (outbound results + return lookups for each). This causes frequent curl: (28) Operation timed out failures on CI runners.
Affected tests (currently commented out):
test_basic_round_trip_searchtest_complex_round_trip_searchtest_round_trip_with_selected_outboundtest_round_trip_result_structure
Proposed solution
Mock the HTTP client (fli.search.client) so these tests validate the round-trip search logic (recursive calls, result pairing, segment selection) without depending on network access. The one-way search tests in the same file have the same issue but are less prone to timeouts since they only make a single API call.
Ideally, all tests in tests/search/ should be refactored to mock the HTTP layer, with real API integration tests gated behind a separate marker (e.g. @pytest.mark.integration).
Problem
The round-trip search tests in
tests/search/test_search_flights.pymake real HTTP requests to the Google Flights API. Round-trip searches are especially slow because they make multiple sequential API calls (outbound results + return lookups for each). This causes frequentcurl: (28) Operation timed outfailures on CI runners.Affected tests (currently commented out):
test_basic_round_trip_searchtest_complex_round_trip_searchtest_round_trip_with_selected_outboundtest_round_trip_result_structureProposed solution
Mock the HTTP client (
fli.search.client) so these tests validate the round-trip search logic (recursive calls, result pairing, segment selection) without depending on network access. The one-way search tests in the same file have the same issue but are less prone to timeouts since they only make a single API call.Ideally, all tests in
tests/search/should be refactored to mock the HTTP layer, with real API integration tests gated behind a separate marker (e.g.@pytest.mark.integration).