You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by "P. Ottlinger" <po...@apache.org> on 2017/01/05 21:51:07 UTC

using assertj for better test matchers - objections?

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

Re: using assertj for better test matchers - objections?

Posted by "P. Ottlinger" <po...@apache.org>.
Hi,

Am 11.01.2017 um 13:45 schrieb Florian Stendel (Apache):
> 
> Imho, the later is a easy to read and understand as your assertj example
> (without introducing the dependency to another library).
> Not to mention, you have one line per test assertion (one for the
> NotNull check, and one for the size check)
> 


The problem with the old matchers is the order of the arguments - which
one is expected/actual.

If you have more complex test assertions/setups you may easily want to
have a more fluent way to check your assertions instead of a chain of
"older" asserts.

Furthermore fluent assertions improve the readability when they mix a
plain logical assertions (e.g. a specific value of 4711) with more
languageSpecific stuff like checkin for (absence/existence) of null or a
particular size of a collection.

But it's merely a matter of taste :-)

Cheers,
Phil

Re: using assertj for better test matchers - objections?

Posted by "Florian Stendel (Apache)" <fl...@gmx.de>.
Hi there,


im just a stray (regarding this project) but what is the benefit of writing

assertThat(change.getChanges()).isNotNull().isNotEmpty().hasSize(1);

instead of

        assertNotNull(change.getChanges());
        assertEquals(1, change.getChanges().size());

?

Imho, the later is a easy to read and understand as your assertj example 
(without introducing the dependency to another library).
Not to mention, you have one line per test assertion (one for the 
NotNull check, and one for the size check)


Kind regards

Florian


Am 06.01.2017 um 12:43 schrieb Oliver B. Fischer:
> 1+, if you/we overhaul all existing tests and forbid the usage of 
> org.junit.Assert. Otherwise it is just another pet in our zoo.
>
>
> Am 05.01.17 um 22:51 schrieb P. Ottlinger:
>> 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
>


Re: using assertj for better test matchers - objections?

Posted by "P. Ottlinger" <po...@apache.org>.
Am 07.01.2017 um 20:31 schrieb P. Ottlinger:
> Unfortunately I'm unable to import assertJ -
> can someone help me, please?

kudos to Oliver - he spotted my typo ;-)

n8
Phil


Re: using assertj for better test matchers - objections?

Posted by "P. Ottlinger" <po...@apache.org>.
Hi again,

Am 06.01.2017 um 23:03 schrieb P. Ottlinger:
> I'm beginning to understand those random build failures .... our
> structure is very complex ...

in case someone can point me to my mistake .... attached you can find my
changes to the current incubator-tamaya-extensions.

Unfortunately I'm unable to import assertJ -
can someone help me, please?

Cheers,
Phil

Re: using assertj for better test matchers - objections?

Posted by "P. Ottlinger" <po...@apache.org>.
Am 06.01.2017 um 12:43 schrieb Oliver B. Fischer:
> 1+, if you/we overhaul all existing tests and forbid the usage of
> org.junit.Assert. Otherwise it is just another pet in our zoo.

I tried to integrate assertj (as naiive as I am :-()
but we seem to have yet another odd repository since we do not rely on
maven central, but
https://repo.maven.apache.org/maven2

There's no assertj available :-(

[ERROR] Failed to execute goal on project tamaya-events: Could not
resolve dependencies for project
org.apache.tamaya.ext:tamaya-events:jar:0.3-incubating-SNAPSHOT: Could
not find artifact org.assertj:assertj.core:jar:3.6.1 in central
(https://repo.maven.apache.org/maven2) -> [Help 1]

Can I add maven central or is there a reason for it not being part of
our extensions build?

I'm beginning to understand those random build failures .... our
structure is very complex ...

Any ideas?

Cheers,
Phil










Re: using assertj for better test matchers - objections?

Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
1+, if you/we overhaul all existing tests and forbid the usage of 
org.junit.Assert. Otherwise it is just another pet in our zoo.


Am 05.01.17 um 22:51 schrieb P. Ottlinger:
> 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

-- 
N Oliver B. Fischer
A Sch�nhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf


Re: using assertj for better test matchers - objections?

Posted by "Florian Stendel (Apache)" <fl...@gmx.de>.
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 <po...@apache.org> 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
>>


Re: using assertj for better test matchers - objections?

Posted by Werner Keil <we...@gmail.com>.
+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 <po...@apache.org> 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
>