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
---
Spring Data GemFire > Nightly-ApacheGeode > #1015 was successful.
---
Scheduled with changes by Oliver Gierke.
2425 tests in total.
https://build.spring.io/b
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, A
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 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
We are using the default algorithm provided by JDK and the proposed
parameter is made boolean as there is no foresee for using different
algorithms. I have the PR#2346[1] for review.
[1] https://github.com/apache/geode/pull/2346
On Fri, Aug 17, 2018, 8:50 AM Jacob Barrett wrote:
> Are we implem
