Conversation
…esponse assertion method. Introduce AssertResponsesInReverseOrder for handling response assertions in reverse. Update logging for no response expectations in various test fixtures.
|
Triggered a Github Actions job to update fixtures. |
github-actions
bot
removed
the
regenerate-fixtures
|
Triggered a Github Actions job to update fixtures. |
…n reverse order. Update testListBlpopNoTimeout to utilize the new functionality and adjust response assertion method accordingly. Modify test fixtures to reflect changes in client connection ports.
| type BlockingClientGroupTestCase struct { | ||
| clientsWithExpectedResponses []clientWithExpectedResponse | ||
| clientsWithExpectedResponses []clientWithExpectedResponse | ||
| ShouldAssertResponsesInReverseOrder bool |
There was a problem hiding this comment.
@andy1li my question was more related to do we need to ever control the order of assertions? Can we always use the reverse order? (Does the logic not apply to all stages?)
There was a problem hiding this comment.
@rohitpaulk Just checked:
-
When alway asserting in reverse,
make testraises no error. -
For other stages using
BlockingClientGroupTestCase, all include only one expectation, so the order does not make a difference.
So let's go with alway asserting in reverse?
There was a problem hiding this comment.
Yep! Can remove the configuration option and keep things simple
…n flag. Update testListBlpopNoTimeout to reflect this change. Adjust test fixtures to ensure consistent client connection ports.
|
Triggered a Github Actions job to update fixtures. |
github-actions
bot
removed
the
regenerate-fixtures
3 participants
Send commands in ascending order of client number
Assert the
NoExpectedResponsebefore the BLPOP response