Summary
AzureMonitorLogsTool (app/tools/AzureMonitorLogsTool/) has no unit tests. Unlike most other integration-wave tools, this one makes direct httpx calls (no dedicated service client abstraction), so the tests need to patch at the httpx level.
Context
The tool is a @tool-decorated function with:
_azure_available(sources) — checks connection_verified, workspace_id, and access_token in sources["azure"]
_azure_extract_params(sources) — maps workspace_id, access_token, endpoint, query, time_range_minutes, limit, max_results
- The
run function uses httpx.post() to query the Azure Log Analytics API — this is the call to patch in tests
The tool also enforces a hard limit (_MAX_HARD_LIMIT = 200) and a bounded limit helper. Both warrant testing.
What to implement
Create tests/tools/test_azure_monitor_logs_tool.py covering:
- Contract test — inherit
BaseToolContract from tests/tools/conftest.py
is_available — True when workspace_id, access_token, and connection_verified are all set; False when any is missing
extract_params — assert workspace_id, access_token, endpoint, and defaults for time_range_minutes and limit are correct
- Bounded limit helper — unit test
_bounded_limit() directly: e.g., _bounded_limit(300, 100) should return 100 (capped at _MAX_HARD_LIMIT)
run happy path — patch httpx.post to return a mocked response with status 200 and a KQL result payload; assert available: True and correct log rows in output
run HTTP error path — patch to return 401 or 403 and assert a graceful error dict with available: True, error: ...
run unavailable path — assert available: False when called without credentials
Acceptance criteria
References
- Pattern:
tests/tools/test_coralogix_logs_tool.py (also patches HTTP calls)
- Tool source:
app/tools/AzureMonitorLogsTool/__init__.py
- Related integration tests:
tests/integrations/test_azure_sql.py (different tool, same Azure namespace)
Summary
AzureMonitorLogsTool(app/tools/AzureMonitorLogsTool/) has no unit tests. Unlike most other integration-wave tools, this one makes directhttpxcalls (no dedicated service client abstraction), so the tests need to patch at thehttpxlevel.Context
The tool is a
@tool-decorated function with:_azure_available(sources)— checksconnection_verified,workspace_id, andaccess_tokeninsources["azure"]_azure_extract_params(sources)— maps workspace_id, access_token, endpoint, query, time_range_minutes, limit, max_resultsrunfunction useshttpx.post()to query the Azure Log Analytics API — this is the call to patch in testsThe tool also enforces a hard limit (
_MAX_HARD_LIMIT = 200) and a bounded limit helper. Both warrant testing.What to implement
Create
tests/tools/test_azure_monitor_logs_tool.pycovering:BaseToolContractfromtests/tools/conftest.pyis_available—Truewhen workspace_id, access_token, and connection_verified are all set;Falsewhen any is missingextract_params— assert workspace_id, access_token, endpoint, and defaults for time_range_minutes and limit are correct_bounded_limit()directly: e.g.,_bounded_limit(300, 100)should return 100 (capped at_MAX_HARD_LIMIT)runhappy path — patchhttpx.postto return a mocked response with status 200 and a KQL result payload; assertavailable: Trueand correct log rows in outputrunHTTP error path — patch to return 401 or 403 and assert a graceful error dict withavailable: True, error: ...rununavailable path — assertavailable: Falsewhen called without credentialsAcceptance criteria
tests/tools/test_azure_monitor_logs_tool.pycreatedmake test-covpassesmake lintpassesReferences
tests/tools/test_coralogix_logs_tool.py(also patches HTTP calls)app/tools/AzureMonitorLogsTool/__init__.pytests/integrations/test_azure_sql.py(different tool, same Azure namespace)