test: point apigee-llm-proxy-url at the renamed test method

[innoprej]

Please ensure you have read the contribution guide before creating a pull request.

Link to Issue or Description of Change

1. Link to an existing issue (if applicable):

• Closes: N/A
• Related: feat: Add chat-completions API support to ApigeeLlm #1249 (feat: Add chat-completions API support to ApigeeLlm), which renamed the test method

2. Or, if no issue exists, describe the change:

Problem:

core/pom.xml has a surefire execution, apigee-llm-proxy-url, that is meant to run one ApigeeLlmTest method with APIGEE_PROXY_URL=proxy-url, so that ApigeeLlm's fallback to that environment variable is tested. The execution selects the method by name:

<test>ApigeeLlmTest#build_withoutProxyUrl_readsFromEnvironment</test>

#1249 replaced that method with build_withoutProxyUrlAndEnvVarSet_readsFromEnvironment, build_withoutProxyUrlAndEnvVarNotSet_throwsException and build_withProxyUrl_usesProvidedUrl, and left the execution pointing at the old name. Since then the execution runs nothing. From the JDK 17 job of the validation run for #1487, which touches neither file (job log):

[INFO] --- surefire:3.5.2:test (apigee-llm-proxy-url) @ google-adk ---
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

The new build_withoutProxyUrlAndEnvVarSet_readsFromEnvironment starts with assumeNotNull(System.getenv("APIGEE_PROXY_URL")), and this is the only execution that sets the variable. In the same job the method is skipped in apigee-llm (24 run, 1 skipped), and in default-test and basic it is skipped along with the rest of ApigeeLlmTest, which needs GOOGLE_API_KEY. So nothing in the build covers the case where APIGEE_PROXY_URL supplies the proxy URL; only the unset case (build_withoutProxyUrlAndEnvVarNotSet_throwsException) runs.

The build does not flag this. Surefire's failIfNoSpecifiedTests check, on by default, only fails when no test class matches the pattern, and ApigeeLlmTest still matches.

Solution:

Point the execution at the new method name. No other change.

Testing Plan

Unit Tests:

• I have added or updated unit tests for my change. (Build configuration only; it re-enables an existing test.)
• All unit tests pass locally, except one pre-existing Windows-only failure described below.

Windows 11, Microsoft OpenJDK 17.0.19, Maven 4.0.0-rc-3 via mvnw:

Run	main	This change
./mvnw -pl core test-compile surefire:test@apigee-llm-proxy-url	Tests run: 0	Tests run: 1: build_withoutProxyUrlAndEnvVarSet_readsFromEnvironment passes
./mvnw -pl core test -Dmaven.test.failure.ignore=true (so that all six executions run)	not run	default-test and basic: 1883 run, 24 skipped, 1 failure each, the pre-existing Windows path-separator case LocalSkillSourceTest.testListResources (addressed separately in #1542). vertex-ai-rag-retrieval 2, apigee-llm 24 (1 skipped), apigee-llm-vertex-ai 1, apigee-llm-proxy-url 1, all passing

Manual End-to-End (E2E) Tests:

Run ./mvnw -pl core test-compile surefire:test@apigee-llm-proxy-url and read the execution's summary: Tests run: 0 on main, Tests run: 1 with this change.

Checklist

• I have read the CONTRIBUTING.md document.
• My pull request contains a single commit.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas. (One-line configuration change.)
• I have added tests that prove my fix is effective or that my feature works. (Re-enables an existing test.)
• New and existing unit tests pass locally with my changes, apart from the pre-existing Windows-only failure noted above.
• I have manually tested my changes end-to-end.
• Any dependent changes have been merged and published in downstream modules.

Additional context

The execution already starts its own JVM; with this change it also runs one test. For scale, in the same CI job apigee-llm-vertex-ai, which runs one test the same way, took about 3.3 seconds from start to finish, and apigee-llm-proxy-url took about 1.4 seconds with no tests.

If you would rather have the build catch this kind of drift, surefire's failIfNoTests (off by default) fails an execution that completes no tests, so setting it on the executions that select tests by name would do that. I left it out to keep this change to one line.

Found while running the core tests on Windows for #1542.

[hemasekhar-p]

Hi @innoprej, thank you for your contribution! We appreciate you taking the time to submit this pull request. Currently this PR is under review by our team and we will keep you posted if any additional information is required. thank you.