You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
New test to port (done with test_chaining_distance_piscine_caen.py but maybe too complex) #38
testName: "should find that Sivom swimming pool in Mondeville is the nearest pool to the LUX cinema in Caen, and that the walking distance is 29 minutes",userInput: "Quel est le temps de marche exact entre le cinéma LUX, situé au sud-est de Caen, et la piscine la plus proche ?",toolMode: "mcp",requiredToolCalls: ["geocode","gpf_search_types","gpf_describe_type","gpf_get_features","distance"],expectedResponseFragments: ["Sivom","Mondeville"],assertScenarioResult: ({ normalizedFinalMessage })=>{expect(containsNumberInRange(normalizedFinalMessage,25,35)).toBe(true);},
The scenario is ported in #47 (test_chaining_distance_piscine_caen.py), but it is too complex for the goal of these tests: checking that the tools work properly with different models, not testing the models' reasoning capabilities.
To pass it, the model has to resolve an ambiguous place ("cinéma LUX", where geocode returns a tram station), discover the right WFS table, search for the nearest pool, then call distance. A failure therefore says more about the model's reasoning than about the tools. For example, claude-haiku-4-5 fails because it takes the first pool returned by geocode (Campus 1, 52 min), while claude-sonnet-4-6 passes (Sivom, Mondeville, 29.5 min).
The simpler geocode → distance test (test_chaining_geocode_distance.py) fits the purpose of this repository better.
changed the title [-]New test to port[/-][+]New test to port (done with test_chaining_distance_piscine_caen.py but maybe too complex)[/+]on Oct 6, 2026
Activity
mborne commentedon Oct 5, 2026
Proposal: close this issue in favour of the new, more focused issues on 0.10.x test coverage:
distancetool: the LUX cinema / Sivom pool scenario from Addtimemetric andcarandpedestrianprofiles toDistanceToolgeocontext#207 is now tracked there, alongside a simplergeocode+distancetest.travel_time_filter, Test E2E - add a test for intersects_feature_filter (0.10.x) #42intersects_feature_filter, Test E2E - add tests for gpf_get_features_layer and gpf_get_feature_by_id_layer (0.10.x) #43_layertools, Test E2E - add tests for spatial_extras (0.10.x) #44spatial_extras/order_by/select.Any objection?
mborne commentedon Oct 5, 2026
The scenario is ported in #47 (
test_chaining_distance_piscine_caen.py), but it is too complex for the goal of these tests: checking that the tools work properly with different models, not testing the models' reasoning capabilities.To pass it, the model has to resolve an ambiguous place ("cinéma LUX", where
geocodereturns a tram station), discover the right WFS table, search for the nearest pool, then calldistance. A failure therefore says more about the model's reasoning than about the tools. For example, claude-haiku-4-5 fails because it takes the first pool returned bygeocode(Campus 1, 52 min), while claude-sonnet-4-6 passes (Sivom, Mondeville, 29.5 min).The simpler
geocode→distancetest (test_chaining_geocode_distance.py) fits the purpose of this repository better.[-]New test to port[/-][+]New test to port (done with test_chaining_distance_piscine_caen.py but maybe too complex)[/+]