Jonathan Halterman

In some use cases, it would be nice to be able to capturing assertion failures to report later without necessarily waiting on anything. Ex: ```java runInThread() -> { waiter.assertTrue(false); });...

Handle uncaught exceptions

1

Idea from here http://stackoverflow.com/questions/30778485/whats-the-correct-way-to-test-runnables-that-can-not-be-directly-seen-by-a-ju/30789208#30789208 Handle failures in threads running code that cannot be modified.

Consider an API to wrap closures that can handle any failures and re-throw them in the main test thread. Ex: ``` messageBus.registerHandler(waiter.handleFailures(() -> msg -> { throw SomethingBadException(); }); ```

Add verifyResumes

1

Add a method to verify resumes - ex: `verifyResumes(int)`. This could be useful to assert that resume is not called more than expected, such as after await is unblocked.

There's never really an appropriate time to wait forever in a test. Therefore, await() should be deprecated.

See Awaitility - keep it simple.

Build queue/exchange recovery where an individual channel (or all channels) can be directed to recover queues/exchanges that are declared through the channel

2

Exchanges/queues/bindings should be scoped by connection.

Add support for handling consumer cancellations. These can occur separate from channel closures. Recovery could perform a single attempt. Cancellations could occur if, for example, a bound queue were deleted....

When a channel is killed by a call in a ChannelListener or ConsumerListener (such as the result of a 404 error), subsequent listeners will be invoked on the channel. This...