junit-devel

[Junit-devel] reintroduction of assertion variants for primitive types?

[Yanic I. <yan...@te...>]

Hi all,

re: org.junit.Assert.java      (rev 1.1.2.7, "Version4" branch, 
"NewYears2006" tag)

In this commit (by kbeck) the decision was made to remove all 
'superfluous' assertEquals variants for primitive types from 
org.junit.Assert and rely on auto-boxing and the Object-based variant 
instead.

Have you taken into consideration that some programmers are not that 
keen (yet?) on auto-boxing and have their compiler set to report 
warnings/errors when auto-boxing is detected?

To circumvent such warnings/errors in their testcode, these programmers 
have to forsake assertEquals and use assertTrue (which is not as 
legible, neither in testcode nor in testrunner output). IMHO the 
framework shouldn't force the use of auto-boxing on its users. 
Auto-boxing can easily be avoided by providing variants for each 
primitive type (as it was before), at no cost and without breaking 
existing code.

Any chance on a reintroduction of these assertEquals (and related) 
variants for primitive types?

Best regards,
Yanic

Re: [Junit-devel] reintroduction of assertion variants for primitive types?

[David S. <sa...@mi...>]

Yanic,

It's a point well-taken.  We'll discuss it for 4.2.  In the meantime, do 
any compilers support @SuppressWarnings("autobox") or something like 
that?  If so, you could create your own Assert class with the desired 
methods.

    David Saff

Yanic Inghelbrecht wrote:
> Hi all,
>
> re: org.junit.Assert.java      (rev 1.1.2.7, "Version4" branch, 
> "NewYears2006" tag)
>
> In this commit (by kbeck) the decision was made to remove all 
> 'superfluous' assertEquals variants for primitive types from 
> org.junit.Assert and rely on auto-boxing and the Object-based variant 
> instead.
>
> Have you taken into consideration that some programmers are not that 
> keen (yet?) on auto-boxing and have their compiler set to report 
> warnings/errors when auto-boxing is detected?
>
> To circumvent such warnings/errors in their testcode, these 
> programmers have to forsake assertEquals and use assertTrue (which is 
> not as legible, neither in testcode nor in testrunner output). IMHO 
> the framework shouldn't force the use of auto-boxing on its users. 
> Auto-boxing can easily be avoided by providing variants for each 
> primitive type (as it was before), at no cost and without breaking 
> existing code.
>
> Any chance on a reintroduction of these assertEquals (and related) 
> variants for primitive types?
>
> Best regards,
> Yanic
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat 
> certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel

Re: [Junit-devel] reintroduction of assertion variants for primitive types?

[Yanic I. <yan...@te...>]

Hi David,

I don't know of any relevant @SuppressWarnings annotations, but Eclipse 
has a compiler option (under 'Error/Warnings', 'J2SE 5.0 options') 
called 'Boxing and  unboxing conversions' that can be set to Ignore, 
Warning or Error. Mine is set to Error.

Best regards,
Yanic





David Saff wrote:
> Yanic,
>
> It's a point well-taken.  We'll discuss it for 4.2.  In the meantime, 
> do any compilers support @SuppressWarnings("autobox") or something 
> like that?  If so, you could create your own Assert class with the 
> desired methods.
>
>    David Saff
>
> Yanic Inghelbrecht wrote:
>> Hi all,
>>
>> re: org.junit.Assert.java      (rev 1.1.2.7, "Version4" branch, 
>> "NewYears2006" tag)
>>
>> In this commit (by kbeck) the decision was made to remove all 
>> 'superfluous' assertEquals variants for primitive types from 
>> org.junit.Assert and rely on auto-boxing and the Object-based variant 
>> instead.
>>
>> Have you taken into consideration that some programmers are not that 
>> keen (yet?) on auto-boxing and have their compiler set to report 
>> warnings/errors when auto-boxing is detected?
>>
>> To circumvent such warnings/errors in their testcode, these 
>> programmers have to forsake assertEquals and use assertTrue (which is 
>> not as legible, neither in testcode nor in testrunner output). IMHO 
>> the framework shouldn't force the use of auto-boxing on its users. 
>> Auto-boxing can easily be avoided by providing variants for each 
>> primitive type (as it was before), at no cost and without breaking 
>> existing code.
>>
>> Any chance on a reintroduction of these assertEquals (and related) 
>> variants for primitive types?
>>
>> Best regards,
>> Yanic
>>
>>
>> -------------------------------------------------------
>> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
>> Fully trained technicians. The highest number of Red Hat 
>> certifications in
>> the hosting industry. Fanatical Support. Click to learn more
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
>> _______________________________________________
>> Junit-devel mailing list
>> Jun...@li...
>> https://lists.sourceforge.net/lists/listinfo/junit-devel
>
>
>
>