Assert.assertEquals() arguments flipped?

[testng...@opensymphony.com]

Is it the intention that the arguments from Assert.assertEquals() don't match the JUnit once?

In JUnit:

assertEquals( "some text when things go wrong", expectedResult, actualResult );

In TestNG:

Assert.assertEquals( actualResult, expectedResult, "some text when things go wrong" );

I believe that this makes the code harder to read because people are used to the argument set used in JUnit. If TestNG flips this, you have to be very aware that you're looking at TestNG code, not JUnit. Also it makes the transition from JUnit to TestNG a lot harder. (BTW: in the TOC of the manual there is an item "3.2.12 Converting from JUnit", but that chapter does not exist)

regards,

Wim

---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=1715&messageID=5288#5288

[testng...@opensymphony.com]

Some time ago on the TestNG ML a discussion about the parameter order in assert methods has taken place. We decided at that moment that - at least for us- it would make more sense to have this order: actualValue, expectedValue [, message]. We had a hard time deciding if this switch will not create problems to the users, and finally we decided to support both ways.
To conclude:
- com.beust.testng.Assert uses actualValue, expectedValue [,message]
- com.beust.testng.AssertJUnit uses [message,] expectedValue, actualValue

It is not our intention to make you switch but my impression is that it is easier to read the following:
assertEquals(computeValue() , 356, "damn this year is different");

--:alex |.::the_mindstorm::.|

---------------------------------------------------------------------
Posted via Jive Forums

http://forums.opensymphony.com/thread.jspa?threadID=1715&messageID=5289#5289

[testng...@opensymphony.com]

ok, thank you for the clarification. If you add documentation on the Assert class, be sure to mention this. I think many JUnit users will have the same question.

---------------------------------------------------------------------
Posted via Jive Forums

http://forums.opensymphony.com/thread.jspa?threadID=1715&messageID=5293#5293

[mortench]

I wish I was around when this discussion took place. Considering the
buildin assert statements in JDK1.4+, as I see it, the whole point of
the Assert class is be able to accept JUnit-like test classes with very
few changes (i.e. new packagname, some @Test attributes - thats it).
That enables easy migration to TestNG tests which you want to support
in order for TestNG to be a true sucess.

By have one Assert class that has a different parameter order and
another Junit like class that has changed name to AssertJUnit , the
WORST posssible decision has been made!! I recommend that you fix this
as soon as possible. One easy way would be to introduce a compability
package called JUnit that would contain a Assert class named Assert
with the JUnit parameter order!

[Cedric Beust]

> From: mortench [mailto:mort...@gmail.com]

Mmmh, ok, I see what you are getting at. In converting from JUnit to
TestNG, we assumed that people wouldn't mind changing:

import org.junit.Assert;

to

import com.beust.testng.AssertJUnit;

which is all that's needed, really. Besides, they will *have* to modify the
import anyway, if only to change the package name...

Is it really such a big deal? What does everyone think?

--
Cédric
http://beust.com/weblog

[mortench]

Not only do the previous JUnit users have to change the import package
they also have to change each and every statement using the class from
Assert.assertXXX to AssertJUnit.assertXXX.

This means that potentially hundreds of lines or more needs to be
changed in a file. I think this is a pretty big deal.

[Alexandru Popescu]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[quote mortench::on 4/21/2005 6:11 PM]

> I wish I was around when this discussion took place. Considering the
> buildin assert statements in JDK1.4+, as I see it, the whole point of
> the Assert class is be able to accept JUnit-like test classes with very
> few changes (i.e. new packagname, some @Test attributes - thats it).
> That enables easy migration to TestNG tests which you want to support
> in order for TestNG to be a true sucess.
>

No, the main reason in not this. The main reason was that -ea is not default in JDK1.4 and JDK1.3
has nothing in this field.

> By have one Assert class that has a different parameter order and
> another Junit like class that has changed name to AssertJUnit , the
> WORST posssible decision has been made!!

I am not sure i understand why this is [quote]the WORST possible decision[/quote]. While migrating
JUnit tests to TestNG you will be required to manage the imports (so you will have to remove/change
the junit.framework.Assert/TestCase and add the com.beust.testng.AssertJUnit). This is imo not
different from having a com.beust.testng.junit.Assert import.

As regards the new com.beust.testng.Assert utility class: as i already explained it seems to us more
readable and this is why we pushed it in.

> I recommend that you fix this
> as soon as possible. One easy way would be to introduce a compability
> package called JUnit that would contain a Assert class named Assert
> with the JUnit parameter order!
>
>

cheers,
- --:alex |.::the_mindstorm::.|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCZ+QsOCPjdDT2FEURAgsDAJ4wmbsPkzKrzsAh8xVcQTMQ/FD1SwCgpTCh
K4ALjh6jOuKWvWvBPjIYLdY=
=JMAk
-----END PGP SIGNATURE-----

[Alexandru Popescu]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[quote mortench::on 4/21/2005 6:31 PM]

Afaik TestCase is extending Assert (in JUnit) and the majority of users are just writting:
assertXXX, so still the change is needed. Maybe if this is required a tool in the 'sed' idea can be
created to solve this.

- --:alex |.::the_mindstorm::.|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCZ+S8OCPjdDT2FEURAkluAJ9lUAjmXStVSqHmeTKQwvzuEtxgdQCgo/FD
qc2UABqHzpbzcAI78PeMMEw=
=0ujM
-----END PGP SIGNATURE-----

[Steven Buroff]

I've just gotten used to the way TestNG's Assert.xxx works - please
don't change it again. In addition, I agree that it's more logical.

Steve Buroff

>
> --
> Cédric
> http://beust.com/weblog
>
>
>

[Alexandru Popescu]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[quote Steven Buroff::on 4/21/2005 6:41 PM]

Thanks Steve ! (this is a very nice confirmation for us)

- --:alex |.::the_mindstorm::.|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCZ+apOCPjdDT2FEURAiCGAKDBva4EfsJ1G3kUQquGoNMNk1gbIQCgvhod
UvsEpvQsvPz/8ZYktewBvI0=
=VHCI
-----END PGP SIGNATURE-----

[mortench]

>>No, the main reason in not this. The main reason was that -ea is not
>>default in JDK1.4 and JDK1.3
>>has nothing in this field.

Point taken about JDK1.3 (did not know you supported 1.3).

>>am not sure i understand why this is [quote]the WORST possible
>>decision[/quote]. While migrating
>>JUnit tests to TestNG you will be required to manage the imports (so
you will >>have to remove/change
>>the junit.framework.Assert/TestCase and add the
>>com.beust.testng.AssertJUnit). This is imo not
>>different from having a com.beust.testng.junit.Assert import.

Sorry for the unecessary strong language. This is one of the
"dangerous" things about entusiastic TestNG users like me :-)

The real issue here - as I wrote I another post minutes ago - is that
people that want to migrate JUnit test will need to change each and
every reference to Assert to AssertJUnit in the code. This means A LOT
of changes in all the test code and NOT only import changes. If you
would have sticked with the JUnit compatible parameters in Assert or
called the TestNG assertion class something different this could have
been avoided.

[Alexandru Popescu]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[quote mortench::on 4/21/2005 6:46 PM]

already answered that too ;-).

- --:alex |.::the_mindstorm::.|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCZ+dVOCPjdDT2FEURAr2hAJ9BSPQLLoZPGUKE3LIzihjYtvQUigCfXKH5
gwuJruxHi3kBKJ5R+GRQbTs=
=KxEH
-----END PGP SIGNATURE-----

[mortench]

What I am saying is that the AssertJunit class should be renamed to
Assert and placed in another package (possibly the orginal Junit
package). That way you won't have to change your TestNG Assert usage
and JUnit people can migrate to TestNG more easily.

[Cedric Beust]

> From: mortench [mailto:mort...@gmail.com]

> The real issue here - as I wrote I another post minutes ago -
> is that people that want to migrate JUnit test will need to
> change each and every reference to Assert to AssertJUnit in
> the code. This means A LOT of changes in all the test code
> and NOT only import changes. If you would have sticked with
> the JUnit compatible parameters in Assert or called the
> TestNG assertion class something different this could have
> been avoided.

As Alexandru already said, they will have to change the import anyway and it
just means they will have to modify this particular line in two places
instead of one... doesn't seem like a big deal to me.

Besides, if they are really converting, they will be using JUnitConverter,
which will take care of all this for them automatically (and more!) :-)

--
Cédric

[Cedric Beust]

> From: mortench [mailto:mort...@gmail.com]

... or they can keep junit.jar in their classpath and not change anything...

--
Cédric

[mortench]

>>As Alexandru already said, they will have to change the import anyway
and it
>>just means they will have to modify this particular line in two
places
>>instead of one... doesn't seem like a big deal to me.

Are we talking past each other ? It is not just one line in each Test
class that needs to be changed. It is much, much more. If I have a test
file with 1 import and 1000 Assert.assertXXX statements, I have to
change Assert to AssertJUnit in 1001 places in this single test class
(and that is just for one class/file). How can you say that this is not
a big deal ?

[Cedric Beust]

> From: mortench [mailto:mort...@gmail.com]

> >>As Alexandru already said, they will have to change the
> import anyway
> and it
> >>just means they will have to modify this particular line in two
> places
> >>instead of one... doesn't seem like a big deal to me.
>
> Are we talking past each other ?

Yes, you seem to have missed Alexandru's answer :-)

> It is not just one line in
> each Test class that needs to be changed. It is much, much
> more. If I have a test file with 1 import and 1000
> Assert.assertXXX statements, I have to change Assert to
> AssertJUnit in 1001 places in this single test class (and
> that is just for one class/file). How can you say that this
> is not a big deal ?

As far as I can tell, JUnit developers never use the syntax
"Assert.assertTrue()", since assertTrue() is defined on TestCase, which
their test extends. They only use assertTrue(), which won't need to be
modified.

The only modification needed is the import line.

--
Cédric

[mortench]

>As far as I can tell, JUnit developers never use the syntax
>"Assert.assertTrue()", since assertTrue() is defined on TestCase,
which
>their test extends. They only use assertTrue(), which won't need to
be
>modified.

Ok, now I understand you better! In most of my projects
Assert.assertXXX is used rather than just assertXXX. Let's hope this is
not a widespread practice in case other users like myself switch to
TestNG (in wich case my recommendation of moving the JUnit stuff into
another package and having the JUnit compability class remain being
called Assert is the better choice).

[Cedric Beust]

> From: mortench [mailto:mort...@gmail.com]

> Ok, now I understand you better! In most of my projects
> Assert.assertXXX is used rather than just assertXXX. Let's
> hope this is not a widespread practice in case other users
> like myself switch to TestNG (in wich case my recommendation
> of moving the JUnit stuff into another package and having the
> JUnit compability class remain being called Assert is the
> better choice).

Point taken, it wouldn't be a problem for us to include JUnit's original
assert class in its package in the TestNG distribution.

We were also discussing with Alexandru about the possibility to have
JUnitConverter take care of that (replace any Assert.assert that it
encounters with AssertJUnit.assert).

Ultimately, I still think that this kind of massive conversion is better
done in an automated way:

- Either with JUnitConverter
- Or using a refactoring IDE

--
Cédric