+1
On Mon, Aug 27, 2018 at 10:06 AM, Kirk Lund wrote:
> Jira ticket as been filed for this:
>
> GEODE-5639: Replace usage of CatchException with AssertJ and remove
> CatchException dependency
>
> On Thu, Aug 23, 2018 at 4:03 PM, Kirk Lund wrote:
>
> > I goofed on #1. We should be using*
Jira ticket as been filed for this:
GEODE-5639: Replace usage of CatchException with AssertJ and remove
CatchException dependency
On Thu, Aug 23, 2018 at 4:03 PM, Kirk Lund wrote:
> I goofed on #1. We should be using* org.assertj.core.api.**Assertions*
> directly, not
For black box testing expected exceptions thrown by background threads of
Geode, we'll need to add appropriate User APIs on a case-by-case basis.
Neither CatchException or AssertJ will help in this case unless there's a
way to get a reference to what was thrown.
On Fri, Aug 24, 2018 at 4:55 PM,
Kirk, Yes I have seen this thread. But in my case,
In my case, the exception is in a background thread.
SerialGatewaySenderEventProcessor uses
ConnectionPool to initiate and send events in the background when the test
code does a put. So
the test code is in not control to handle or even catch
Hey Sai, did you see this thread? It might help with your exception testing
that you asked about. DeltaPropagationFailureRegressionTest and
RegisterInterestDistributedTest (mentioned below) are both dunit tests.
On Thu, Aug 23, 2018 at 4:03 PM, Kirk Lund wrote:
> I goofed on #1. We should be
I goofed on #1. We should be using* org.assertj.core.api.**Assertions*
directly, not *AssertionsForClassTypes*.
1) Basic assertion about an expected exception
Use: org.assertj.core.api.Assertions.assertThatThrownBy
Example from JdbcWriterTest:
assertThatThrownBy(() ->
We have a small number of tests
using com.googlecode.catchexception.CatchException. This project isn't very
active and AssertJ provides better support for testing expected exceptions
and throwables. Most Geode developers are already using AssertJ for
expected exceptions.
I propose we update the
