junit-devel — junit developers

[Junit-devel] junit 3.8 source code

[Julius S. <Jul...@Su...>]

Hi All,

I would like to have a look at junit 3.8 source code how things are 
implemented. Where can I get a source of that ancient version? It is not 
available on sourceforge. Thanks in advance.

Cheers

Julo

Re: [Junit-devel] antlib

[J. D. B. <jd...@ge...>]

J. David Beutel wrote:
> is JUnit's CPL 1.0 compatible with Ant's Apache License 2.0?
>   

I am not a lawyer, but to answer my own question, I don't see any 
problem.  CPL 1.0 says:

Contributions do not include additions to
the Program which: (i) are separate modules of software distributed in
conjunction with the Program under their own license agreement, and (ii) are
not derivative works of the Program.


and Apache 2.0 says:

For the purposes of this License, Derivative Works shall not include 
works that remain separable from, or merely link (or bind by name) to 
the interfaces of, the Work and Derivative Works thereof.

So I suppose that code under these respective licenses can call, 
implement, or extend each other, and be distributed together, without 
any virulence of the kind intended by the GPL.

Cheers,
11011011

Re: [Junit-devel] antlib

[J. D. B. <jd...@ge...>]

Thanks, I would like to take a shot at it, or at least see how far I can 
get.  It should include the junit and junitreport tasks.

It could be distributed separately from both, but if I'm not mistaken 
about antlib, it could also be distributed in the same JAR as JUnit.  
This makes me wonder, is JUnit's CPL 1.0 compatible with Ant's Apache 
License 2.0?

Speaking of all-in-one, I noticed that Hamcrest distributes its source 
and class files together in the same JAR.  I'd never seen that before, 
but I like not having separate files that can get out of sync.

Cheers,
11011011

David Saff wrote:
> David,
>
> I don't know of anyone working on such a thing, but it would likely be
> valuable.  Would you like to give it a whirl?  Thanks,
>
>    David Saff
>
> On 8/27/07, J. David Beutel <jd...@ge...> wrote:
>   
>> Is anyone working on an antlib for JUnit?  The support for JUnit 4 in
>> Ant 1.7 is OK, but could stand some improvements in the reporting, e.g.,
>> for @Ignore, the 4.4 assumptions, the way it continues to simulate the
>> distinction between failure and error, and a timezone for the timestamps.
>>
>> Cheers,
>> 11011011

Re: [Junit-devel] antlib

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

David,

I don't know of anyone working on such a thing, but it would likely be
valuable.  Would you like to give it a whirl?  Thanks,

   David Saff

On 8/27/07, J. David Beutel <jd...@ge...> wrote:
> Is anyone working on an antlib for JUnit?  The support for JUnit 4 in
> Ant 1.7 is OK, but could stand some improvements in the reporting, e.g.,
> for @Ignore, the 4.4 assumptions, the way it continues to simulate the
> distinction between failure and error, and a timezone for the timestamps.
>
> Cheers,
> 11011011
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>

[Junit-devel] antlib

[J. D. B. <jd...@ge...>]

Is anyone working on an antlib for JUnit?  The support for JUnit 4 in 
Ant 1.7 is OK, but could stand some improvements in the reporting, e.g., 
for @Ignore, the 4.4 assumptions, the way it continues to simulate the 
distinction between failure and error, and a timezone for the timestamps.

Cheers,
11011011

[Junit-devel] [parabuild] BUILD for junit (#54) on localhost was BROKEN: Script returned non-zero code "1"

[Build A. <vim...@vi...>]

BUILD result
------------------------------------------------------------

BUILD for junit (#54) on localhost was BROKEN: Script returned non-zero code "1"

Build status:
  http://parabuild.viewtier.com:8080/parabuild/index.htm?view=detailed&buildid=5


Suspect Changes
------------------------------------------------------------

Change(s) by dsaff :

 - Reorganize tests;
   Time: 06:29 AM 08/20/2007; Change list: 8481

Change(s) Details:
  http://parabuild.viewtier.com:8080/parabuild/build/changes.htm?buildrunid=5499

BUILD logs
------------------------------------------------------------

BUILD log:
  http://parabuild.viewtier.com:8080/parabuild/build/log.htm?logid=7683
Error Lines:
  http://parabuild.viewtier.com:8080/parabuild/build/log.htm?logid=7684

Log Lines Around Error
------------------------------------------------------------

       [java] 	at org.junit.runner.JUnitCore.run(JUnitCore.java:109)
       [java] 	at org.junit.runner.JUnitCore.run(JUnitCore.java:100)
       [java] 	at org.junit.runner.JUnitCore.runMain(JUnitCore.java:81)
       [java] 	at org.junit.runner.JUnitCore.main(JUnitCore.java:44)
       [java] 2) testError(org.junit.tests.listening.TextListenerTest)
       [java] junit.framework.AssertionFailedError: null
       [java] 	at junit.framework.Assert.fail(Assert.java:47)
       [java] 	at junit.framework.Assert.assertTrue(Assert.java:20)
       [java] 	at junit.framework.Assert.assertTrue(Assert.java:27)
       [java] 	at org.junit.tests.listening.TextListenerTest.testError(TextListenerTest.java:44)
       [java] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       [java] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
       [java] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       [java] 	at java.lang.reflect.Method.invoke(Method.java:585)
       [java] 	at junit.framework.TestCase.runTest(TestCase.java:168)
       [java] 	at junit.framework.TestCase.runBare(TestCase.java:134)
       [java] 	at junit.framework.TestResult$1.protect(TestResult.java:110)
       [java] 	at junit.framework.TestResult.runProtected(TestResult.java:128)
       [java] 	at junit.framework.TestResult.run(TestResult.java:113)
       [java] 	at junit.framework.TestCase.run(TestCase.java:124)
       [java] 	at junit.framework.TestSuite.runTest(TestSuite.java:232)
       [java] 	at junit.framework.TestSuite.run(TestSuite.java:227)
       [java] 	at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:80)
       [java] 	at org.junit.internal.runners.CompositeRunner.runChildren(CompositeRunner.java:33)
  BUILD FAILED
       [java] 	at org.junit.runners.Suite.access$000(Suite.java:25)
  /opt/parabuild/etc/build/b5co/a/u/t/o/junit/build.xml:117: Java returned: 1
       [java] 	at org.junit.runners.Suite$1.run(Suite.java:92)
       [java] 	at org.junit.internal.runners.Roadie.runProtected(Roadie.java:81)
  Total time: 40 seconds
       [java] 	at org.junit.internal.runners.TestClass.runProtected(TestClass.java:100)
       [java] 	at org.junit.runners.Suite.run(Suite.java:90)
       [java] 	at org.junit.internal.runners.CompositeRunner.runChildren(CompositeRunner.java:33)
       [java] 	at org.junit.internal.runners.CompositeRunner.run(CompositeRunner.java:28)
       [java] 	at org.junit.runner.JUnitCore.run(JUnitCore.java:130)
       [java] 	at org.junit.runner.JUnitCore.run(JUnitCore.java:109)
       [java] 	at org.junit.runner.JUnitCore.run(JUnitCore.java:100)
       [java] 	at org.junit.runner.JUnitCore.runMain(JUnitCore.java:81)
       [java] 	at org.junit.runner.JUnitCore.main(JUnitCore.java:44)
       [java] 3) successCausesExitCodeOf0(org.junit.tests.running.core.JUnitCoreTest)
       [java] java.lang.AssertionError: expected:<0> but was:<1>
       [java] 	at org.junit.Assert.fail(Assert.java:74)
       [java] 	at org.junit.Assert.failNotEquals(Assert.java:448)
       [java] 	at org.junit.Assert.assertEquals(Assert.java:102)
       [java] 	at org.junit.Assert.assertEquals(Assert.java:323)
       [java] 	at org.junit.Assert.assertEquals(Assert.java:319)
       [java] 	at org.junit.tests.running.core.JUnitCoreTest.runClass(JUnitCoreTest.java:44)
       [java] 	at org.junit.tests.running.core.JUnitCoreTest.successCausesExitCodeOf0(JUnitCoreTest.java:34)
       [java] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       [java] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

Timings
------------------------------------------------------------

BUILD took 43 seconds 

Re: [Junit-devel] Developing JUnit in NetBeans

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

Daria,

Thanks for this.  Does this depend on new features in NetBeans?  Also,
it looks like you may have grabbed junit-4.4.jar in the first 22 hours
it was out: this version still had imposterization packages, which
were left in by mistake.  We released a new version the next day that
fixed the problem.  Thanks,

   David Saff

On 8/16/07, Daria Titova <Dar...@su...> wrote:
> Dear JUnit developers,
>
> I would like to let you know that we have recently ported JUnit
> environment into the NetBeans IDE.
> You may wish to check it out:
> http://wiki.netbeans.org/wiki/view/NetbeansedJUnit
>
> Now you can build and test JUnit inside the NetBeans IDE, and have
> access to all nifty features the NetBeans IDE provides to make
> developers more productive and happy.
>
> I would greatly appreciate any feedback you may have about my project
> and any ideas on how to make it more useful for JUnit community.
>
> If you are new to NetBeans please go to http://www.netbeans.org for all
> information, tutorials and fun stuff.
>
> Daria Titova
> NetBeans Engineer.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>

[Junit-devel] Developing JUnit in NetBeans

[Daria T. <Dar...@Su...>]

Dear JUnit developers,

I would like to let you know that we have recently ported JUnit 
environment into the NetBeans IDE.
You may wish to check it out:
http://wiki.netbeans.org/wiki/view/NetbeansedJUnit

Now you can build and test JUnit inside the NetBeans IDE, and have 
access to all nifty features the NetBeans IDE provides to make 
developers more productive and happy.

I would greatly appreciate any feedback you may have about my project 
and any ideas on how to make it more useful for JUnit community.

If you are new to NetBeans please go to http://www.netbeans.org for all 
information, tutorials and fun stuff.

Daria Titova
NetBeans Engineer.

Re: [Junit-devel] JUnit 4.4 released

[Slava I. <vim...@vi...>]

Hi All,

I have been a silent reader for a while. I should say that this recent
addition to JUnit has caused a lot of confusion. JUnit used to be a
clean, lightweight library. I think it would be great if it is kept
this way. 

Wouldn't it make more sense to drop hamcrest from JUnit and let the
hamcrest develop it in a way so that it can be easily plugged in into
JUnit [if needed]?

Regards,

Slava Imeshev


> -----Original Message-----
> From: jun...@li... 
> [mailto:jun...@li...] On Behalf 
> Of Mauro Talevi
> Sent: Monday, August 13, 2007 10:28 AM
> To: jun...@li...
> Subject: Re: [Junit-devel] JUnit 4.4 released
> 
> David Saff wrote:
> 
> > It is easy to spot fail-fast problems, but not necessarily 
> easy to fix 
> > them--we have at least one user a month who posts to the user list

> > confused about how to get just the single junit.jar on their 
> > classpath.
> > 
> > I'm saying that both are problems, and any solution is a
trade-off.
> > My personal hunch is that if you ask Java developers the first jar

> > they ever put on their classpath, JUnit scores high, and I'm very 
> > concerned about making that experience any more complicated than 
> > necessary.
> 
> I agree - it's a trade-off based on how one uses the library, 
> and also on personal preferences.
> But then again, the number of libraries that one adds to the 
> classpath is growing rapidly,
> with all the available open-source projects.   And the 
> emphasis is on modularisation and 
> re-usability, ie best practice, rather than the potential 
> problems of a novice.
> 
> > On the other hand, so much of the complexity here is 
> unnecessary.  I 
> > believe that a vanilla Java installation should include a 
> jpkg command 
> > line, so that the answer to the first JUnit FAQ could be:
> > 
> > jpkg install junit
> > 
> > It would be great if end-users didn't have to care how many 
> jar files 
> > were installed to make that work, or even what a jar file is.
> > 
> >> - by bundling hamcrest-core you are also surrendering the 
> advantage of a clear versioned dependency
> >>     structure, which is extremely important with so many 
> open-source 
> >> libraries, all interconnected among them.  A lot of people 
> nowadays 
> >> use maven or maven-like repositories for their project 
> dependencies.
> > 
> > I'd love to see more people use maven (it's the closest 
> thing to the 
> > mythical jpkg we have), so making life hard for them is not good.
> > However, I think that there's still more people who are
downloading 
> > the jar manually from the website, and still more who just use 
> > whatever ships with their IDE, so balance is important.
> > 
> 
> Well, I don't know much about jpkg, but from it docs it seems 
> to be similar to Gentoo Portage.
> 
> In any case, any sofware management tool will necessarily 
> have dependency management.
> 
> Maven put's a lot of emphasis on dependency management - and 
> it's precisely for the reason of keeping dependency 
> management nice and simple that it's important to be able to 
> have the option to use libraries with unbundled dependencies.
> 
> >> Ideally, I would like to see junit released with all its 
> constituent 
> >> libraries - mandatory or optional - separate.  And perhaps have a

> >> junit-all that bundles all of the them, including 
> hamcrest-library, 
> >> as a utility packaging for those that choose to use it.  
> Other users may choose not to.
> >>
> >> Alternately, I would be grateful if junit could also release the 
> >> unbundled jar - call it junit-dep or whatever, which 
> requires the external dependency to be present in the classpath.
> > 
> > I think that the second is the right solution.  Look for 
> further news 
> > soon.  Thanks,
> > 
> 
> Cool - I'll look forward to it.   Do you think you could 
> re-release 4.4 with the additional 
> unbundled junit jar?   Or simply release the additional unbundled
jar.
> 
> Thanks, Mauro
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and 
> a browser.
> Download your FREE copy of Splunk now >>  
> http://get.splunk.com/
_______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
> 

Re: [Junit-devel] JUnit 4.4 released

[Mauro T. <mau...@aq...>]

David Saff wrote:

> It is easy to spot fail-fast problems, but not necessarily easy to fix
> them--we have at least one user a month who posts to the user list
> confused about how to get just the single junit.jar on their
> classpath.
> 
> I'm saying that both are problems, and any solution is a trade-off.
> My personal hunch is that if you ask Java developers the first jar
> they ever put on their classpath, JUnit scores high, and I'm very
> concerned about making that experience any more complicated than
> necessary.

I agree - it's a trade-off based on how one uses the library, and also on personal preferences.
But then again, the number of libraries that one adds to the classpath is growing rapidly,
with all the available open-source projects.   And the emphasis is on modularisation and 
re-usability, ie best practice, rather than the potential problems of a novice.

> On the other hand, so much of the complexity here is unnecessary.  I
> believe that a vanilla Java installation should include a jpkg command
> line, so that the answer to the first JUnit FAQ could be:
> 
> jpkg install junit
> 
> It would be great if end-users didn't have to care how many jar files
> were installed to make that work, or even what a jar file is.
> 
>> - by bundling hamcrest-core you are also surrendering the advantage of a clear versioned dependency
>>     structure, which is extremely important with so many open-source libraries, all interconnected
>> among them.  A lot of people nowadays use maven or maven-like repositories for their project
>> dependencies.
> 
> I'd love to see more people use maven (it's the closest thing to the
> mythical jpkg we have), so making life hard for them is not good.
> However, I think that there's still more people who are downloading
> the jar manually from the website, and still more who just use
> whatever ships with their IDE, so balance is important.
> 

Well, I don't know much about jpkg, but from it docs it seems to be similar to Gentoo Portage.

In any case, any sofware management tool will necessarily have dependency management.

Maven put's a lot of emphasis on dependency management - and it's precisely for the reason of 
keeping dependency management nice and simple that it's important to be able to have the option to 
use libraries with unbundled dependencies.

>> Ideally, I would like to see junit released with all its constituent libraries - mandatory or
>> optional - separate.  And perhaps have a junit-all that bundles all of the them, including
>> hamcrest-library, as a utility packaging for those that choose to use it.  Other users may choose
>> not to.
>>
>> Alternately, I would be grateful if junit could also release the unbundled jar - call it junit-dep
>> or whatever, which requires the external dependency to be present in the classpath.
> 
> I think that the second is the right solution.  Look for further news
> soon.  Thanks,
> 

Cool - I'll look forward to it.   Do you think you could re-release 4.4 with the additional 
unbundled junit jar?   Or simply release the additional unbundled jar.

Thanks, Mauro

Re: [Junit-devel] JUnit 4.4 released

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

Mauro,

On 8/9/07, Mauro Talevi <mau...@aq...> wrote:
> - you ae selling as a benefit having a single jar as opposed to two - junit and hamcrest-core - when
> the user would still have to download separatedly hamcrest-library.  Does not make a big difference
> to download 2 or 3 files, IMHO.

Actually, on my latest project, I've just been using the matchers in
junit-4.4.jar, and it's been going great.  So at least this user is
doing fine with one jar.  :-)

Do you yourself need hamcrest-library for what you're doing?

> - the classpath problems would not manifest themselves if the hamcrest-core dependency was missing,
> or in any case it would be easy to spot fail-fast problems, as opposed to really nasty problems due
> to different versions of hamcrest-core, one embedded and one not, in the classpath.

It is easy to spot fail-fast problems, but not necessarily easy to fix
them--we have at least one user a month who posts to the user list
confused about how to get just the single junit.jar on their
classpath.

I'm saying that both are problems, and any solution is a trade-off.
My personal hunch is that if you ask Java developers the first jar
they ever put on their classpath, JUnit scores high, and I'm very
concerned about making that experience any more complicated than
necessary.

On the other hand, so much of the complexity here is unnecessary.  I
believe that a vanilla Java installation should include a jpkg command
line, so that the answer to the first JUnit FAQ could be:

jpkg install junit

It would be great if end-users didn't have to care how many jar files
were installed to make that work, or even what a jar file is.

>
> - by bundling hamcrest-core you are also surrendering the advantage of a clear versioned dependency
>     structure, which is extremely important with so many open-source libraries, all interconnected
> among them.  A lot of people nowadays use maven or maven-like repositories for their project
> dependencies.

I'd love to see more people use maven (it's the closest thing to the
mythical jpkg we have), so making life hard for them is not good.
However, I think that there's still more people who are downloading
the jar manually from the website, and still more who just use
whatever ships with their IDE, so balance is important.

> Ideally, I would like to see junit released with all its constituent libraries - mandatory or
> optional - separate.  And perhaps have a junit-all that bundles all of the them, including
> hamcrest-library, as a utility packaging for those that choose to use it.  Other users may choose
> not to.
>
> Alternately, I would be grateful if junit could also release the unbundled jar - call it junit-dep
> or whatever, which requires the external dependency to be present in the classpath.

I think that the second is the right solution.  Look for further news
soon.  Thanks,

   David

Re: [Junit-devel] JUnit 4.4 released

[Mauro T. <mau...@aq...>]

David Saff wrote:
> Mauro,
> 
> The idea was to bundle only hamcrest-core, a small package that the
> hamcrest team has told us is likely to change very rarely.  The
> majority of the hamcrest matchers are in hamcrest-library, which can
> be downloaded separately.  So, to get all of JUnit and all of
> Hamcrest, without overlaps, you would download junit-x.x.jar, and
> hamcrest-library-x.x.jar.
> 
> There are downsides to this arrangement.  My initial guess is that the
> number of people who will find themselves with classpath problems
> because they're using an incompatible version of hamcrest-all will be
> less than the number who would have found themselves with classpath
> problems because they don't have hamcrest, or couldn't figure out
> which junit jar to download.
> 
> Of course, experience has a way of proving me wrong.  We'll see.
> 

David,

I do understand the idea behind the decision, but IMO on balance it's likely to lead to problems 
down the line.  Let me outline the reasons again:

- you ae selling as a benefit having a single jar as opposed to two - junit and hamcrest-core - when 
the user would still have to download separatedly hamcrest-library.  Does not make a big difference 
to download 2 or 3 files, IMHO.

- while hamcrest-core is likely to change rarely, it is still likely to change
(Murphy's law of dependency:  if a dependency can change, it will :-)

- the classpath problems would not manifest themselves if the hamcrest-core dependency was missing,
or in any case it would be easy to spot fail-fast problems, as opposed to really nasty problems due 
to different versions of hamcrest-core, one embedded and one not, in the classpath.

- by bundling hamcrest-core you are also surrendering the advantage of a clear versioned dependency 
    structure, which is extremely important with so many open-source libraries, all interconnected 
among them.  A lot of people nowadays use maven or maven-like repositories for their project 
dependencies.


Ideally, I would like to see junit released with all its constituent libraries - mandatory or 
optional - separate.  And perhaps have a junit-all that bundles all of the them, including 
hamcrest-library, as a utility packaging for those that choose to use it.  Other users may choose 
not to.

Alternately, I would be grateful if junit could also release the unbundled jar - call it junit-dep 
or whatever, which requires the external dependency to be present in the classpath.

This seems to me a reasonable compromise that should satisfy all users.

Do you think this could be done?

Thanks and regards,
Mauro

Re: [Junit-devel] JUnit 4.4 released

[Mauro T. <mau...@aq...>]

David Saff wrote:
> Mauro,
> 
> The idea was to bundle only hamcrest-core, a small package that the
> hamcrest team has told us is likely to change very rarely.  The
> majority of the hamcrest matchers are in hamcrest-library, which can
> be downloaded separately.  So, to get all of JUnit and all of
> Hamcrest, without overlaps, you would download junit-x.x.jar, and
> hamcrest-library-x.x.jar.
> 
> There are downsides to this arrangement.  My initial guess is that the
> number of people who will find themselves with classpath problems
> because they're using an incompatible version of hamcrest-all will be
> less than the number who would have found themselves with classpath
> problems because they don't have hamcrest, or couldn't figure out
> which junit jar to download.
> 
> Of course, experience has a way of proving me wrong.  We'll see.
> 

David,

I do understand the idea behind the decision, but IMO on balance it's likely to lead to problems 
down the line.  Let me outline the reasons again:

- you ae selling as a benefit having a single jar as opposed to two - junit and hamcrest-core - when 
the user would still have to download separatedly hamcrest-library.  Does not make a big difference 
to download 2 or 3 files, IMHO.

- while hamcrest-core is likely to change rarely, it is still likely to change
(Murphy's law of dependency:  if a dependency can change, it will :-)

- the classpath problems would not manifest themselves if the hamcrest-core dependency was missing,
or in any case it would be easy to spot fail-fast problems, as opposed to really nasty problems due 
to different versions of hamcrest-core, one embedded and one not, in the classpath.

- by bundling hamcrest-core you are also surrendering the advantage of a clear versioned dependency 
    structure, which is extremely important with so many open-source libraries, all interconnected 
among them.  A lot of people nowadays use maven or maven-like repositories for their project 
dependencies.


Ideally, I would like to see junit released with all its constituent libraries - mandatory or 
optional - separate.  And perhaps have a junit-all that bundles all of the them, including 
hamcrest-library, as a utility packaging for those that choose to use it.  Other users may choose 
not to.

Alternately, I would be grateful if junit could also release the unbundled jar - call it junit-dep 
or whatever, which requires the external dependency to be present in the classpath.

This seems to me a reasonable compromise that should satisfy all users.

Do you think this could be done?

Thanks and regards,
Mauro

Re: [Junit-devel] JUnit 4.4 released

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

Mauro,

The idea was to bundle only hamcrest-core, a small package that the
hamcrest team has told us is likely to change very rarely.  The
majority of the hamcrest matchers are in hamcrest-library, which can
be downloaded separately.  So, to get all of JUnit and all of
Hamcrest, without overlaps, you would download junit-x.x.jar, and
hamcrest-library-x.x.jar.

There are downsides to this arrangement.  My initial guess is that the
number of people who will find themselves with classpath problems
because they're using an incompatible version of hamcrest-all will be
less than the number who would have found themselves with classpath
problems because they don't have hamcrest, or couldn't figure out
which junit jar to download.

Of course, experience has a way of proving me wrong.  We'll see.

   David Saff

On 7/29/07, Mauro Talevi <mau...@aq...> wrote:
> David,
>
> David Saff wrote:
>
> > - To allow compatibility with a wide variety of possible matchers,
> >   we have decided to include the classes from hamcrest-core,
> >   from the [Hamcrest][] project.  This is the first time that
> >   third-party classes have been included in JUnit.
> >
> > [Hamcrest]: http://code.google.com/p/hamcrest/
> >
>
> Bundling classes from a dependent library in the jar will lead to classloader hell unless you
> change package name for the bundled classes.  jMock has Hamcrest as a mandatory but separate
> dependency.   Any reason you did not consider to do the same?  The compatibility motivation you cite
>   is not clear.  It is exactly for compatibility reasons that jars should be kept separate.  If a
> user wants to upgrade to a different version of hamcrest, it will conflict with the classes bundled.
>
> Alternatively, you could provide a *separate* jar (eg junit-all.jar) which bundles with the
> dependencies, but keeping junit.jar without dependendencies bundled.
>
> Thanks and regards,
> Mauro
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>

Re: [Junit-devel] JUnit 4.4 released

[Mauro T. <mau...@aq...>]

David,

David Saff wrote:

> - To allow compatibility with a wide variety of possible matchers,
>   we have decided to include the classes from hamcrest-core,
>   from the [Hamcrest][] project.  This is the first time that
>   third-party classes have been included in JUnit.
> 
> [Hamcrest]: http://code.google.com/p/hamcrest/
> 

Bundling classes from a dependent library in the jar will lead to classloader hell unless you
change package name for the bundled classes.  jMock has Hamcrest as a mandatory but separate 
dependency.   Any reason you did not consider to do the same?  The compatibility motivation you cite 
  is not clear.  It is exactly for compatibility reasons that jars should be kept separate.  If a 
user wants to upgrade to a different version of hamcrest, it will conflict with the classes bundled.

Alternatively, you could provide a *separate* jar (eg junit-all.jar) which bundles with the 
dependencies, but keeping junit.jar without dependendencies bundled.

Thanks and regards,
Mauro

[Junit-devel] Refresh of junit 4.4 files

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

All,

The first release of JUnit 4.4 contained extraneous packages and
libraries that were intended to be removed before release.  We have
removed them, renamed some of the subpackages of
org.junit.experimental, fixed two small bugs, and re-published the 4.4
jars.

If you downloaded before now, please do so again.  This will be the
final release of JUnit 4.4.  Thanks,

   David Saff

[Junit-devel] JUnit 4.4 released

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

All,

We're very pleased to announce the release of JUnit 4.4.  This release
is the biggest since JUnit 4.0.  More information below (taken from
the release notes).  To download, please go to

http://sourceforge.net/project/showfiles.php?group_id=15278&package_id=12472&release_id=524119

Thanks to all of the bug reports, feature requests, and good
conversation so far.  We hope this release will provoke more of the
same.

   David Saff and Kent Beck

## Summary of Changes in version 4.4 ##

JUnit is designed to efficiently capture developers' intentions about
their code, and quickly check their code matches those intentions.
Over the last year, we've been talking about what things developers
would like to say about their code that have been difficult in the
past, and how we can make them easier.

### assertThat ###

Two years ago, Joe Walnes built a [new assertion mechanism][walnes] on
top of what was
then [JMock 1][].  The method name was `assertThat`, and the syntax
looked like this:

[walnes]: http://joe.truemesh.com/blog/000511.html
[JMock 1]: http://www.jmock.org/download.html

    assertThat(x, is(3));
    assertThat(x, is(not(4)));
    assertThat(responseString,
either(containsString("color")).or(containsString("colour")));
    assertThat(myList, hasItem("3"));

More generally:

    assertThat([value], [matcher statement]);

Advantages of this assertion syntax include:

- More readable and typeable: this syntax allows you to think in terms
of subject, verb, object
  (assert "x is 3") rather than `assertEquals`, which uses verb,
object, subject (assert "equals 3 x")

- Combinations: any matcher statement `s` can be negated (`not(s)`),
combined (`either(s).or(t)`),
  mapped to a collection (`each(s)`), or used in custom combinations
(`afterFiveSeconds(s)`)

- Readable failure messages.  Compare

        assertTrue(responseString.contains("color") ||
responseString.contains("colour"));
        // ==> failure message:
        // java.lang.AssertionError:

        assertThat(responseString, anyOf(containsString("color"),
containsString("colour")));
        // ==> failure message:
        // java.lang.AssertionError:
        // Expected: (a string containing "color" or a string
containing "colour")
        //      got: "Please choose a font"

- Custom Matchers.  By implementing the `Matcher` interface yourself,
you can get all of the
  above benefits for your own custom assertions.

- For a more thorough description of these points, see [Joe Walnes's
  original post][walnes].

We have decided to include this API directly in JUnit.
It's an extensible and readable syntax, and it enables
new features, like [assumptions][] and [theories][].

[assumptions]: #assumptions
[theories]: #theories

Some notes:

- The old assert methods are never, ever, going away.  Developers may
  continue using the old `assertEquals`, `assertTrue`, and so on.
- The second parameter of an `assertThat` statement is a `Matcher`.
  We include the Matchers we want as static imports, like this:

        import static org.hamcrest.CoreMatchers.is;

  or:

        import static org.hamcrest.CoreMatchers.*;

- Manually importing `Matcher` methods can be frustrating.  [Eclipse
3.3][] includes the ability to
  define
  "Favorite" classes to import static methods from, which makes it easier
  (Search for "Favorites" in the Preferences dialog).
  We expect that support for static imports will improve in all Java
IDEs in the future.

[Eclipse 3.3]: http://www.eclipse.org/downloads/

- To allow compatibility with a wide variety of possible matchers,
  we have decided to include the classes from hamcrest-core,
  from the [Hamcrest][] project.  This is the first time that
  third-party classes have been included in JUnit.

[Hamcrest]: http://code.google.com/p/hamcrest/

- JUnit currently ships with a few matchers, defined in
  `org.hamcrest.CoreMatchers` and `org.junit.matchers.JUnitMatchers`.
  To use many, many more, consider downloading the [full hamcrest package][].

[full hamcrest package]:
http://hamcrest.googlecode.com/files/hamcrest-all-1.1.jar

- JUnit contains special support for comparing string and array
  values, giving specific information on how they differ.  This is not
  yet available using the `assertThat` syntax, but we hope to bring
  the two assert methods into closer alignment in future releases.

<a name="assumptions" />
### Assumptions ###

Ideally, the developer writing a test has control of all of the forces
that might cause a test to fail.
If this isn't immediately possible, making dependencies explicit can
often improve a design.
For example, if a test fails when run in a different locale than the
developer intended,
it can be fixed by explicitly passing a locale to the domain code.

However, sometimes this is not desirable or possible.
It's good to be able to run a test against the code as it is currently written,
implicit assumptions and all, or to write a test that exposes a known bug.
For these situations, JUnit now includes the ability to express "assumptions":

    import static org.junit.Assume.*

    @Test public void filenameIncludesUsername() {
       assumeThat(File.separatorChar, is('/'));
       assertThat(new User("optimus").configFileName(),
is("configfiles/optimus.cfg"));
    }

    @Test public void correctBehaviorWhenFilenameIsNull() {
       assumeTrue(bugFixed("13356"));  // bugFixed is not included in JUnit
       assertThat(parse(null), is(new NullDocument()));
    }

With this release, a failed assumption will lead to the test being
marked as passing,
regardless of what the code below the assumption may assert.
In the future, this may change, and a failed assumption may lead to
the test being ignored:
however, third-party runners do not currently allow this option.

We have included `assumeTrue` for convenience, but thanks to the
inclusion of Hamcrest, we do not need to create `assumeEquals`,
`assumeSame`, and other analogues to the `assert*` methods.  All of
those functionalities are subsumed in `assumeThat`, with the appropriate
matcher.

<a name="theories" />
### Theories ###

More flexible and expressive assertions, combined with the ability to
state assumptions clearly, lead to a new kind of statement of intent,
which we call a "Theory".  A test captures the intended behavior in
one particular scenario.  A theory captures some aspect of the
intended behavior in possibly
infinite numbers of potential scenarios.  For example:

    @RunWith(Theories.class)
    public class UserTest {
      @DataPoint public static String GOOD_USERNAME = "optimus";
      @DataPoint public static String USERNAME_WITH_SLASH = "optimus/prime";

      @Theory public void filenameIncludesUsername(String username) {
        assumeThat(username, not(containsString("/")));
        assertThat(new User(username).configFileName(),
containsString(username));
      }
    }

This makes it clear that the user's filename should be included in the
config file name, only if it doesn't contain a slash.  Another test
or theory might define what happens when a username does contain a slash.

`UserTest` will attempt to run `filenameIncludesUsername` on
every compatible `DataPoint` defined in the class.  If any of the
assumptions fail, the data point is silently ignored.  If all of the
assumptions pass, but an assertion fails, the test fails.

The support for Theories has been absorbed from the [Popper][]
project, and [more complete documentation][popper-docs] can be found
there.

[Popper]: http://popper.tigris.org
[popper-docs]: http://popper.tigris.org/tutorial.html

Defining general statements in this way can jog the developer's memory
about other potential data points and tests, also allows [automated
tools][junit-factory] to [search][my-blog] for new, unexpected data
points that expose bugs.

[junit-factory]: http://www.junitfactory.org
[my-blog]: http://shareandenjoy.saff.net/2007/04/popper-and-junitfactory.html

### Other changes ###

This release contains other bug fixes and new features.  Among them:

- Annotated descriptions

  Runner UIs, Filters, and Sorters operate on Descriptions of test
  methods and test classes.  These Descriptions now include the
  annotations on the original Java source element, allowing for richer
  display of test results, and easier development of annotation-based
  filters.

- Bug fix (1715326): assertEquals now compares all Numbers using their
  native implementation of `equals`.  This assertion, which passed in
  4.3, will now fail:

        assertEquals(new Integer(1), new Long(1));

  Non-integer Numbers (Floats, Doubles, BigDecimals, etc),
  which were compared incorrectly in 4.3, are now fixed.

- `assertEquals(long, long)` and `assertEquals(double, double)` have
  been re-introduced to the `Assert` class, to take advantage of
  Java's native widening conversions.  Therefore, this still passes:

        assertEquals(1, 1L);

- The default runner for JUnit 4 test classes has been refactored.
  The old version was named `TestClassRunner`, and the new is named
  `JUnit4ClassRunner`.  Likewise, `OldTestClassRunner` is now
  `JUnit3ClassRunner`.  The new design allows variations in running
  individual test classes to be expressed with fewer custom classes.
  For a good example, see the source to
  `org.junit.experimental.theories.runner.api.Theories`.

- The rules for determining which runner is applied by default to a
  test class have been simplified:

  1. If the class has a `@RunWith` annotation, the annotated runner
     class is used.

  2. If the class can be run with the JUnit 3 test runner (it
     subclasses `TestCase`, or contains a `public static Test suite()`
     method), JUnit38ClassRunner is used.

  3. Otherwise, JUnit4ClassRunner is used.

  This default guess can always be overridden by an explicit
  `@RunWith(JUnit4ClassRunner.class)` or
  `@RunWith(JUnit38ClassRunner.class)` annotation.

  The old class names `TestClassRunner` and `OldTestClassRunner`
  remain as deprecated.

- Bug fix (1739095): Filters and Sorters work correctly on test
  classes that contain a `suite` method like:

        public static junit.framework.Test suite() {
          return new JUnit4TestAdapter(MyTest.class);
        }

- Bug fix (1745048): @After methods are now correctly called
  after a test method times out.

Re: [Junit-devel] Can I log-in instead to see emails?

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

All,

CVS commit messages are now going to the list
jun...@li....  Please sign up there if you'd
still like to get messages.  Right now, it's still one message per
check-in directory--if anyone knows a clever utility to gather
check-in messages, I'd be all ears.

   David Saff

On 7/13/07, Ernst Reissner <re...@ar...> wrote:
> Hello all,
>
> as Dave Mendoza wrote
> > I have been getting too many exchangs by email but I want to remain a subscriber
> >
> what about collecting all messages in a single mail?
>
> Greetings
>
> Ernst
>
> --
>
> ----------------------------------------------------------
> Please avoid sending me Word or PowerPoint attachments.
> See http://www.gnu.org/philosophy/no-word-attachments.html
> ----------------------------------------------------------
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>

Re: [Junit-devel] Can I log-in instead to see emails?

[Ernst R. <re...@ar...>]

Hello all,

as Dave Mendoza wrote
> I have been getting too many exchangs by email but I want to remain a subscriber
>   
what about collecting all messages in a single mail?

Greetings

Ernst

-- 

----------------------------------------------------------
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
----------------------------------------------------------

Re: [Junit-devel] Can I log-in instead to see emails?

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

Dave,

Excellent point.  I'll route the CVS commit messages to another list
so this one will be free for development discussion.  Stay tuned,

   David

On 7/12/07, Dave Mendoza <lda...@gm...> wrote:
> I have been getting too many exchangs by email but I want to remain a subscriber
>
> Thanks
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>

[Junit-devel] CVS: junit build.xml,1.31,1.32

[David S. <ds...@us...>]

Update of /cvsroot/junit/junit
In directory sc8-pr-cvs6.sourceforge.net:/tmp/cvs-serv30443

Modified Files:
	build.xml 
Log Message:
Fix reference to experimental tests in build file


Index: build.xml
===================================================================
RCS file: /cvsroot/junit/junit/build.xml,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -d -r1.31 -r1.32
--- build.xml	9 Jul 2007 20:53:58 -0000	1.31
+++ build.xml	12 Jul 2007 17:17:38 -0000	1.32
@@ -50,7 +50,7 @@
 			debug="on"
 			classpath="${hamcrestlib}"
 			includeantruntime="false"
-			excludes="**/imposterization/**,**/theories/test/**"
+			excludes="**/imposterization/**,**/experimental/test/**"
   		>
 			<compilerarg value="-Xlint:unchecked" />
 		</javac>

[Junit-devel] Can I log-in instead to see emails?

[Dave M. <lda...@gm...>]

I have been getting too many exchangs by email but I want to remain a subscriber

Thanks

[Junit-devel] CVS: junit/src/org/junit Assume.java,1.1,1.2

[David S. <ds...@us...>]

Update of /cvsroot/junit/junit/src/org/junit
In directory sc8-pr-cvs6.sourceforge.net:/tmp/cvs-serv26134/src/org/junit

Modified Files:
	Assume.java 
Log Message:
Re-organize theory packages

Index: Assume.java
===================================================================
RCS file: /cvsroot/junit/junit/src/org/junit/Assume.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- Assume.java	2 Jul 2007 18:11:07 -0000	1.1
+++ Assume.java	12 Jul 2007 17:08:23 -0000	1.2
@@ -8,7 +8,7 @@
 import org.hamcrest.Matcher;
 import org.hamcrest.SelfDescribing;
 import org.hamcrest.StringDescription;
-import org.junit.experimental.theories.matchers.api.Each;
+import org.junit.matchers.Each;
 
 public class Assume {
 	public static class AssumptionViolatedException extends RuntimeException implements SelfDescribing {

[Junit-devel] CVS: junit/src/org/junit/experimental/theories/runner TheoryMethod.java, NONE, 1.1 ConcreteFunction.java, NONE, 1.1 Function.java, NONE, 1.1 TheoryContainerReference.java, 1.1, 1.2

[David S. <ds...@us...>]

Update of /cvsroot/junit/junit/src/org/junit/experimental/theories/runner
In directory sc8-pr-cvs6.sourceforge.net:/tmp/cvs-serv26134/src/org/junit/experimental/theories/runner

Modified Files:
	TheoryContainerReference.java 
Added Files:
	TheoryMethod.java ConcreteFunction.java Function.java 
Log Message:
Re-organize theory packages

--- NEW FILE: TheoryMethod.java ---
/**
 * 
 */
package org.junit.experimental.theories.runner;

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.util.ArrayList;
import java.util.List;

import org.junit.Assert;
import org.junit.Assume.AssumptionViolatedException;
import org.junit.experimental.theories.methods.api.Theory;
import org.junit.internal.runners.TestClass;
import org.junit.internal.runners.TestMethod;

public class TheoryMethod extends TestMethod {
	private final Method fMethod;

	private List<AssumptionViolatedException> fInvalidParameters= new ArrayList<AssumptionViolatedException>();

	public TheoryMethod(Method method, TestClass testClass) {
		super(method, testClass);
		fMethod= method;
	}

	@Override
	public void invoke(Object test) throws IllegalArgumentException,
			IllegalAccessException, InvocationTargetException {
		TheoryContainerReference container= new TheoryContainerReference(
				test);

		ConcreteFunction function= new ConcreteFunction(test, fMethod);

		int runCount= 0;
		try {
			runCount+= container.runWithParameters(this,
					new ArrayList<Object>(), function.signatures());
		} catch (Throwable e) {
			throw new InvocationTargetException(e);
		}
		if (runCount == 0)
			Assert
					.fail("Never found parameters that satisfied method.  Violated assumptions: "
							+ fInvalidParameters);
	}

	public boolean nullsOk() {
		return fMethod.getAnnotation(Theory.class).nullsAccepted();
	}

	public Method getMethod() {
		return fMethod;
	}

	public void addAssumptionFailure(AssumptionViolatedException e) {
		fInvalidParameters.add(e);
	}
}
--- NEW FILE: ConcreteFunction.java ---
/**
 * 
 */
package org.junit.experimental.theories.runner;

import java.lang.reflect.Method;

public class ConcreteFunction extends Function {
	protected final Object target;
	protected final Method method;

	public ConcreteFunction(Object target, Method method) {
		this.target = target;
		this.method = method;
	}

	@Override public Object getTarget() {
		return target;
	}

	@Override public Method getMethod() {
		return method;
	}

	@Override public boolean equals(Object obj) {
		Function function = (Function) obj;

		return targetIs(function.getTarget())
				&& method.equals(function.getMethod());
	}

	private boolean targetIs(Object otherTarget) {
		if (target == null)
			return otherTarget == null;
		return target.equals(otherTarget);
	}

	@Override public String toString() {
		return String.format("%s.%s", target, method);
	}
}
--- NEW FILE: Function.java ---
package org.junit.experimental.theories.runner;

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.lang.reflect.Type;
import java.util.ArrayList;
import java.util.Arrays;

import org.junit.experimental.theories.methods.api.ParameterSignature;


public abstract class Function {
	public abstract Method getMethod();

	public abstract Object getTarget();

	public Object invoke(Object... paramArray) throws Throwable {
		getMethod().setAccessible(true);
		Object[] modParams = modifyParameters(paramArray);
		if (modParams.length != parameterTypes().length)
			throw new IllegalArgumentException(String.format(
					"Wrong number of parameters, passing %s to %s", Arrays
							.asList(modParams), getMethod()));
		try {
			return getMethod().invoke(getTarget(), modParams);
		} catch (InvocationTargetException e) {
			throw e.getTargetException();
		}
	}

	public Throwable exceptionThrown(Object... paramArray) {
		try {
			invoke(paramArray);
		} catch(Throwable t) {
			return t;
		}
		
		return null;
	}

	protected Object[] modifyParameters(Object... paramArray) {
		return paramArray;
	}

	public Type[] parameterTypes() {
		return getMethod().getGenericParameterTypes();
	}

	public Object[] emptyParameterArray() {
		return new Object[parameterTypes().length];
	}

	public Function curryWith(final Object[] curriedParameters) {
		return new Function() {

			@Override public Method getMethod() {
				return Function.this.getMethod();
			}

			@Override public Object getTarget() {
				return Function.this.getTarget();
			}

			@Override protected Object[] modifyParameters(Object... paramArray) {
				ArrayList<Object> list = new ArrayList<Object>();
				list.addAll(Arrays.asList(curriedParameters));
				list.addAll(Arrays.asList(paramArray));
				return list.toArray();
			}
		};
	}

	public ArrayList<ParameterSignature> signatures() {
		return ParameterSignature.signatures(getMethod());
	}
}

Index: TheoryContainerReference.java
===================================================================
RCS file: /cvsroot/junit/junit/src/org/junit/experimental/theories/runner/TheoryContainerReference.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- TheoryContainerReference.java	2 Jul 2007 18:11:15 -0000	1.1
+++ TheoryContainerReference.java	12 Jul 2007 17:08:21 -0000	1.2
@@ -11,10 +11,8 @@
 import java.util.List;
 
 import org.junit.Assume.AssumptionViolatedException;
-import org.junit.experimental.theories.javamodel.api.ConcreteFunction;
 import org.junit.experimental.theories.methods.api.ParameterSignature;
 import org.junit.experimental.theories.methods.api.ParameterSupplier;
-import org.junit.experimental.theories.runner.api.Theories.TheoryMethod;
 
 public class TheoryContainerReference {
 	private final Object container;

[Junit-devel] CVS: junit/src/org/junit/experimental/imposterization FunctionPointer.java, 1.1, 1.2

[David S. <ds...@us...>]

Update of /cvsroot/junit/junit/src/org/junit/experimental/imposterization
In directory sc8-pr-cvs6.sourceforge.net:/tmp/cvs-serv26134/src/org/junit/experimental/imposterization

Modified Files:
	FunctionPointer.java 
Log Message:
Re-organize theory packages

Index: FunctionPointer.java
===================================================================
RCS file: /cvsroot/junit/junit/src/org/junit/experimental/imposterization/FunctionPointer.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- FunctionPointer.java	2 Jul 2007 18:11:02 -0000	1.1
+++ FunctionPointer.java	12 Jul 2007 17:08:21 -0000	1.2
@@ -4,7 +4,7 @@
 
 import org.jmock.api.Invocation;
 import org.jmock.api.Invokable;
-import org.junit.experimental.theories.javamodel.api.Function;
+import org.junit.experimental.theories.runner.Function;
 
 public class FunctionPointer extends Function {
 	public static FunctionPointer pointer() {