fix: enable component client for integration tests #1744
Conversation
| */ | ||
| protected <T> T execute(DeferredCall<Any, T> deferredCall) { | ||
| return execute(deferredCall, timeout); | ||
| } |
There was a problem hiding this comment.
I think we will also need another utility method to allow you to cast a result to a specific type.. noticed this while having:
public sealed interface Response {
record Ok(String msg) implements Response {
public static Ok of(String created) {
return new Ok(created);
}
}
}If the deferredCall method is declaring to return Response and not Response.Ok then the execution will fail on the test with a jackson error not knowing how to construct Response.
But this can be solved as follow-up I think.
There was a problem hiding this comment.
actually, the solution for this problem is a bit different: https://github.com/aludwiko/kalix-saga-patterns/blob/main/src/main/java/com/example/cinema/application/Response.java#L10
| @Autowired | ||
| private ComponentClient componentClient; |
There was a problem hiding this comment.
does that mean that we can wire the ComponentClient anywhere? Like wire it into an Entity?
There was a problem hiding this comment.
No, it's not possible, nothing has changed.
...va-sdk-spring-testkit/src/main/java/kalix/spring/testkit/KalixIntegrationTestKitSupport.java
Show resolved
Hide resolved
| /** | ||
| * Utility method to execute a deferred call and wait for the response for a specified time. | ||
| */ | ||
| protected <T> T execute(DeferredCall<Any, T> deferredCall, Duration timeout) { |
There was a problem hiding this comment.
I'm in doubt if we should add this method. I know that this comes from our own internal test class, but do we need yet another API to offer to users?
In prod code, users will do defferedCall.execute() so we can expect them to do the same in tests.
They can then chain different calls if they want and eventually add .toCompletableFuture().get(timeout) as they would usually do when working with Java Futures.
There was a problem hiding this comment.
I'm not sure about this method as well, my motivation was that such a method will appear in any integration test, but maybe it's fine and better for the user to decide when/if to add it.
There was a problem hiding this comment.
I would remove it. It's just a thin layer on top of a very common CompletionStage operation. We don't need to abstract this away for users.
References #1743