GEODE-3539: add test coverage for "create async-event-queue" and "lis…

[jinmeiliao]

…t async-event-queue"

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

For all changes:

• Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

• Has your PR been rebased against the latest commit within the target branch (typically develop)?

• Is your initial contribution a single, squashed commit?

• Does gradlew build run cleanly?

• Have you written or updated unit tests to verify your changes?

• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

Note:

Please ensure that once the PR is submitted, you check travis-ci for build issues and
submit an update to your PR as soon as possible. If you need help, please send an
email to dev@geode.apache.org.

[pdxrunner]

Point of discussion (not necessary to change, but something to consider) : the signature of {{tableHasRowWithValues}} has {{headersThenValues}}. I didn't notice this from the previous change to CommandResultAssert, but I think that that ordering of the {{String}} arguments as {{header, value}} pairs is more readable. With only one or two values in the row it's not too confusing, but with a longer list of values of interest, then associating the matching header and values becomes less clear when reviewing code that calls the method.

[jinmeiliao]

so you are suggesting the caller should call something like: tableHasRowWithValues("Member,server-2", "ID,queue2")

this would make the processing a bit harder, but still doable. It's just the way these GFJsonObject are constructed, We will have to refactor out this entire result object anyway, good things we are lumping all the processing in this CommandResultAssert object so it's one spot to change.

[pdxrunner]

No, what I would envision is tableHasRowWithValues(Member, server-2, ID, queue2). I would keep the arguments separate but order arguments as pairs ..., header, value, ... . I agree that processing this wouldn't be quite as straightforward as

String[] headers = Arrays.copyOfRange(headersThenValues, 0, numberOfColumn);
String[] expectedValues =
    Arrays.copyOfRange(headersThenValues, numberOfColumn, headersThenValues.length);

[pdxrunner]

Since the catch is no longer for {{Throwable}} a better name for the variable would be 'e'

[jinmeiliao]

precheckin green