test(bigquery-magics): support both old and new table_id parse error formats

[chalmerlowe]

Problem 1:

The unit test test_bigquery_magic_query_variable_not_identifier was asserting that a specific error message (must be a fully-qualified ID) was in the stderr output.

However, in a recent update to google-cloud-bigquery (#17137), this validation error message was updated to:
Could not parse table_id. Expected a table ID...

Because bigquery-magics supports a range of google-cloud-bigquery versions (>= 3.41.0, < 4.0.0), the unit tests run against different versions depending on the Python runtime constraints (e.g., Python 3.10 runs against the lower bound 3.41.0 which has the old error message, while Python 3.11+ runs against the latest version which has the new error message). This caused tests to fail on python 3.10 with the new assertion, and on 3.11+ with the old assertion.

Solution 1:

Update the assertion to that the keyword table_id which is universal to both the old error message and the new error message is present in the result. This ensures that even when we EOL Python 3.10, we won't have to change the test.

assert "table_id" in output

Problem 2:

When testing this solution, it was discovered that there one of the conditional branches does not get tested and thus we did not have full coverage.

Solution 2:

Revised the test_deprecation.py file to avoid that conditional statement. Converted the conditional to match the form of similar conditionals used elsewhere.

Problem 3:

Ran the code with the ruff formatter and that reordered a number of import statements and updated the style on some expressions. SORRY.

Problem 4:

The system test test_bigquery_magic in the bigquery-magics package previously verified connection hygiene by counting process-level active socket connections using psutil.Process().net_connections().

This black-box verification was highly fragile and prone to flakiness because:

• Dynamic Platform Authentication: In testing environments such as Kokoro CI, the google-auth library dynamically instantiates background HTTP sessions to fetch access tokens from local metadata/token servers (e.g. Workload Identity). These connections are pooled or kept alive by the platform and remain open beyond the control of the client library.
• Non-deterministic Garbage Collection: Python socket closure relies on the garbage collection of unreferenced socket objects. If the garbage collector does not run immediately before the ending connection count is measured, the test fails even if there is no actual connection leak.
• Environment Pollution: Process-level checks count sockets opened by any concurrent test or runner background thread in the same process, causing test pollution.

Solution 4:

Replaced the fragile psutil socket connection counts with a mock spy verification:

Spied on the google.cloud.bigquery.Client.close method to verify that client closure is explicitly invoked when the magic execution finishes.
Kept the original close functionality active (side_effect=original_close) to ensure actual cleanup still occurs during the test process.
Removed the process-level psutil assertions entirely, making the test environment-agnostic, deterministic, and faster.

[gemini-code-assist]

Code Review

This pull request updates a unit test assertion in test_bigquery_magic_query_variable_not_identifier to accept either 'must be a fully-qualified ID' or 'Could not parse table_id.' in the standard error output. I have no feedback to provide as there are no review comments.