Test: Using Orchestration Grounding module

[Jonas-Isr]

Context

AI/ai-sdk-java-backlog#125.

Add an end-to-end test of the orchestration grounding module.

Feature scope:

• Add end-to-end test.

Definition of Done

• Functionality scope stated & covered
• Tests cover the scope above
• Error handling created / updated & covered by the tests above
• Aligned changes with the JavaScript SDK
• Documentation updated
• Release notes updated

[CharlesDuboisSAP]

Please add documentation
The grounding app endpoint is broken, the index.html is not updated
I would also like to see a bit more assertions on the e2e test.
And a unit test to assert on all fields of the response, because we don't know if the generated classes can access all fields of the JSON response.

[MatKuhr]

minor notes, lgtm

[newtork]

(Minor/Comment)

I think AssertJ also has ).hasToString( as replacement for .toString()).isEqualTo(.

Do we actually need the string check when we compare the values anyway? AFAIK we didn't do this in other places.

[Jonas-Isr]

I cannot compare the values directly here, as getModuleResults().getGrounding().getData() returns an Object so that I cannot access "grounding_query" or "grounding_result" via the generated code. This is why I compare it as a String.

Also, I use .toString()).startsWith(... now to not need to provide the complete rather long expected String.

If you feel there is a better way to do that, please let me know :)

[MatKuhr]

Object is somewhat misleading, actually this will always be a Map<String, Object>. (Ideally, our generator would be improved in that regard).

So you could cast to that and use .get("grounding_query")

[Jonas-Isr]

Casting this adds a warning, though. Is that a problem?

[MatKuhr]

yes, it's just a test assertion, so it's okay if this ever fails (which would mean we've changed our generator but didn't update tests)