New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ARTEMIS-2488: Handle the case where source address is null #315
Conversation
(cherry picked from commit 2ec96bf) downstream: ENTMQBR-3258
public class ProtonServerSenderContextTest { | ||
|
||
@Test(expected = ActiveMQAMQPNotFoundException.class) | ||
public void testAcceptsNullSourceAddressWhenInitialising() throws Exception { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there any practices about organizing the more "mock heavy" tests? For me, this order of things makes a bit more sense:
@Test(expected = ActiveMQAMQPNotFoundException.class)
public void testAcceptsNullSourceAddressWhenInitialising() throws Exception {
Source source = new Source();
source.setAddress(null);
Sender mockSender = mock(Sender.class);
when(mockSender.getRemoteSource()).thenReturn(source);
AddressQueryResult queryResult = new AddressQueryResult(null, Collections.emptySet(), 0, false, false, false, false, 0);
AMQPSessionCallback mockSessionCallback = mock(AMQPSessionCallback.class);
when(mockSessionCallback.addressQuery(any(), any(), anyBoolean())).thenReturn(queryResult);
AMQPConnectionContext mockConnContext = mock(AMQPConnectionContext.class);
ProtonServerSenderContext sc = new ProtonServerSenderContext(mockConnContext, mockSender, null, mockSessionCallback);
sc.initialise();
}
|
||
AMQPSessionCallback mockSessionCallback = mock(AMQPSessionCallback.class); | ||
|
||
AddressQueryResult queryResult = new AddressQueryResult(null, Collections.emptySet(), 0, false, false, false, false, 0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are mocking too much, IMO. The first null parameter to addressQuery
is supposed to be coming in from calling SimpleString.toSimpleString(source.getAddress());
but here you hardcode the null in queryResult
for whatever value went into calling that addressQuery.
I'd add assert that addressQuery
got called with null, or configure the when(
to only respond with this result for null
as first parameter, or maybe try to avoid mocks as much as possible and use real server instead of mockSessionCallback
or just make the test assert that mockSessionCallback.addressQuery
got called with null
as first parameter.
That initialize() thing is soooo long.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lulf It's probably just me, but I'd still want to just try connecting to a full broker to check if this is fixed. I somehow cannot get myself to trust the mock-rich test above. Especially after some time passes, in future releases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jirkadanek I don't disagree, I'd love to not having to mock that much. However, triggering this from an integration test might be hard, we originally triggered this via an Artemis plugin. Also, my knowledge of the test framework used in Artemis is limited, and this seemed the (believe it or not :) ) the simplest way to write a test for this.
Merged it |
(cherry picked from commit 2ec96bf)
downstream: ENTMQBR-3258