Use AssertJ.
If you find test code that's catching Exception and invoking fail with or
without the caught Exception, convert that to something better. Using fail
is itself an epic fail.
1) Tests should never catch unexpected Exceptions
Remove "catch (Exception" and let the test methods throw the exception.
JUnit's failure messages for uncaught Exceptions is way better than using
fail.
2) Use ErrorCollector rules in callback code such as CacheListeners
@Rule
public ErrorCollector errorCollector = new ErrorCollector();
...
} catch (Exception e) {
errorCollector.addError(e);
}
On Mon, Aug 20, 2018 at 12:47 PM, Patrick Rhomberg <prhomb...@apache.org>
wrote:
> I greatly favor AssertJ-core's `assertThat` and `assertThatThrownBy`.
> Decoupling is nice, but the reported failure information that AssertJ
> includes makes investigating failures initially much easier. That, and
> method-chaining assertions and (rarely) soft-assertions are useful
> features.
>
> On Mon, Aug 20, 2018 at 12:32 PM, Dale Emery <dem...@pivotal.io> wrote:
>
> > Between JUnit and AssertJ, my preference is AssertJ, for two reasons.
> > First is AssertJ’s pervasiveness in Geode. Second, it decouples
> assertions
> > from the testing framework (in support of my secret desire to move to
> JUnit
> > 5).
> >
> > Cheers,
> > Dale
> >
> > > On Aug 20, 2018, at 11:49 AM, Mark Hanson <mhan...@pivotal.io> wrote:
> > >
> > > Hi All,
> > >
> > > In the course fo fixing some tests, I have found that the existing
> Geode
> > asserts are deprecated. In wanting to leave the code as clean of
> > deprecations as possible, I have come to the inevitable quandary. Which
> > Assert should we be using? JUnit or Assertj? I am happy with either
> though
> > I will note that JUnit Assert does not seem to have a fail where you can
> > pass in the exception, which is used a lot in Geode. I look forward to an
> > answer.
> > >
> > > Thanks,
> > > Mark
> > >
> > >
> >
> > —
> > Dale Emery
> > dem...@pivotal.io
> >
> >
>
