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, Sai Boorlagadda <sai.boorlaga...@gmail.com>
wrote:
> 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 exceptions.
>
> So for a black box test (like this one) may be a tool to assert certain
> exception is logged is the only best option?
>
> On Fri, Aug 24, 2018 at 4:02 PM Kirk Lund <kl...@apache.org> wrote:
>
> > 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 <kl...@apache.org> wrote:
> >
> >> 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(() -> writer.beforeUpdate(entryEvent))
> >> .isInstanceOf(IllegalArgumentException.class);
> >>
> >> I'll fix JdbcWriterTest's imports. I copied the import to the email
> >> without looking closely at it.
> >>
> >> On Thu, Aug 23, 2018 at 4:01 PM, Kirk Lund <kl...@apache.org> wrote:
> >>
> >>> 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 few tests using CatchException to instead use
> >>> AssertJ and then remove our testing dependency on CatchException.
> >>>
> >>> The recommended ways of handling expected exception testing would then
> >>> involve using following AssertJ APIs:
> >>>
> >>> 1) Basic assertion about an expected exception
> >>>
> >>> Use: org.assertj.core.api.AssertionsForClassTypes.assertThatThrownBy
> >>>
> >>> Example from JdbcWriterTest:
> >>>
> >>> assertThatThrownBy(() -> writer.beforeUpdate(entryEvent))
> >>> .isInstanceOf(IllegalArgumentException.class);
> >>>
> >>> 2) Complex assertion about an expected exception (potentially with many
> >>> nested causes with messages that we want to validate as well)
> >>>
> >>> Use: org.assertj.core.api.Assertions.catchThrowable
> >>>
> >>> Example from DeltaPropagationFailureRegressionTest:
> >>>
> >>> Throwable thrown = server1.invoke(() -> catchThrowable(() ->
> >>> putDelta(FROM_DELTA)));
> >>>
> >>> assertThat(thrown).isInstanceOf(DeltaSerializationException.class)
> >>> .hasMessageContaining("deserializing delta
> >>> bytes").hasCauseInstanceOf(EOFException.class);
> >>>
> >>> 3) Simple assertion that an invocation should not thrown (probably used
> >>> in a regression test)
> >>>
> >>> Use: org.assertj.core.api.Assertions.assertThatCode
> >>>
> >>> Example from RegisterInterestDistributedTest:
> >>>
> >>> assertThatCode(() ->
> >>> clientCache.readyForEvents()).doesNotThrowAnyException();
> >>>
> >>> Let me know if you can think of another use case that isn't handled by
> >>> the above AssertJ APIs.
> >>>
> >>>
> >>
> >
>
