Ahh sorry,
didn't read this one.
I didn't have a look in your sources. (to find out what version of junit
you are using)
But the very first parameter of 'triplet' assertEquals is indeed a
message used for the AssertionError.
(see
http://junit.sourceforge.net/javadoc/org/junit/Assert.html#assertEquals(java.lang.String,
java.lang.Object, java.lang.Object))
||
public static void*assertEquals*(java.lang.String message,
java.lang.Object expected,
java.lang.Object actual)
Asserts that two objects are equal. If they are not,
an|AssertionError|is thrown with the given message.
If|expected|and|actual|are|null|, they are considered equal.
*Parameters:*
|message|- the identifying message for
the|AssertionError|(|null|okay)
|expected|- expected value
|actual|- actual value
Kind regards
Florian
Am 06.01.2017 um 12:03 schrieb Werner Keil:
+1
We use it a lot in the current project and I started a special module for
JSR 363 for AssertJ in
https://github.com/unitsofmeasurement/uom-lib/tree/master/assertj.
assertTrue(collection.size() == 1) is clearly an antipattern. At the very
least one should have used
assertEquals(1, collection.size(), 0) instead, so if it fails you get a
much better description of what failed.
For that AssertJ also offers further comfort, e.g. its own
AssertionExceptions with detailed information or messages you can override.
Also using that right now e.g. for API smoke tests where it shows exactly
which API call failed and how it deviated from the expected state;-)
Cheers,
Werner
On Thu, Jan 5, 2017 at 10:51 PM, P. Ottlinger <[email protected]> wrote:
Hi,
does anyone object that we use assertj for mor expressive testing matchers?
I just stumbled upon:
assertTrue(change.getChanges().size() == 1);
which would be more clear as
assertThat(change.getChanges()).isNotNull().isNotEmpty().hasSize(1);
Any objections if I add assertJ in test-scope?
Cheers,
Phil
