junit-devel — junit developers

[Junit-devel] JUnit 4.9 released!

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

Hello, everyone.  We're happy to announce the release of JUnit 4.9.
This release's theme is Test-class and suite level Rules.  More
information linked from
http://saffgreenbar.blogspot.com/2011/08/junit-49-released.html, and
release notes below.

Note: please remember that until some website issues are cleared up,
the direct path to the new JavaDoc is at
http://kentbeck.github.com/junit/javadoc/4.9/.

Share and enjoy, and please try it out and give us feedback.  Thanks,

Your friendly neighborhood JUnit maintainers



## Summary of Changes in version 4.9, final ##

Release theme: Test-class and suite level Rules.

### ClassRule ###

The `ClassRule` annotation extends the idea of method-level Rules,
adding static fields that can affect the operation of a whole class.  Any
subclass of `ParentRunner`, including the standard `BlockJUnit4ClassRunner`
and `Suite` classes, will support `ClassRule`s.

For example, here is a test suite that connects to a server once before
all the test classes run, and disconnects after they are finished:

	@RunWith(Suite.class)
	@SuiteClasses({A.class, B.class, C.class})
	public class UsesExternalResource {
		public static Server myServer= new Server();
	
		@ClassRule
		public static ExternalResource resource= new ExternalResource() {
			@Override
			protected void before() throws Throwable {
				myServer.connect();
			};
	
			@Override
			protected void after() {
				myServer.disconnect();
			};
		};
	}

### TestRule ###

In JUnit 4.9, fields that can be annotated with either `@Rule` or `@ClassRule`
should be of type `TestRule`.  The old `MethodRule` type, which only made sense
for method-level rules, will still work, but is deprecated.

Most built-in Rules have been moved to the new type already, in a way that
should be transparent to most users.  `TestWatchman` has been deprecated,
and replaced by `TestWatcher`, which has the same functionality, but implements
the new type.

### Maven support ###

Maven bundles have, in the past, been uploaded by kind volunteers.  Starting
with this release, the JUnit team is attempting to perform this task ourselves.

### LICENSE checked in ###

The Common Public License that JUnit is released under is now included
in the source repository.

### Bug fixes ###

- github#98: assumeTrue() does not work with expected exceptions
- github#74: Categories + Parameterized

  In JUnit 4.8.2, the Categories runner would fail to run correctly
  if any contained test class had a custom Runner with a structure
  significantly different from the built-in Runner.  With this fix,
  such classes can be assigned one or more categories at the class level,
  and will be run correctly.  Trying to assign categories to methods within
  such a class will flag an error.

- github#38: ParentRunner filters more than once

  Thanks to `@reinholdfuereder`

- github#248: protected BlockJUnit4ClassRunner#rules method removed from 4.8.2
- github#187: Accidental dependency on Java 6

Thanks to `@kcooney` for:

- github#163: Bad comparison failure message when using
assertEquals(String, String)
- github#227: ParentRunner now assumes that getChildren() returns a
modifiable list

### Minor changes ###

- Backed out unused folder "experimental-use-of-antunit", replaced by
  bash-based script at build_tests.sh
- Various Javadoc fixes

Thanks to `@kcooney` for:

- Made MultipleFailureException public, to assist extension writers.
- github#240: Add "test" target to build.xml, for faster ant-driven testing.
- github#247: Give InitializationError a useful message

[Junit-devel] JUnit 4.9b4 (beta-)released

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

Hello, everyone.  We're happy to announce the release of JUnit 4.9b4.
This release's theme is Test-class and suite level Rules.  This beta
release contains a number of community-authored fixes for regression
errors in documentation and test class validation.  More information
linked from http://saffgreenbar.blogspot.com/2011/08/junit-49b4-beta-released.html,
and release notes below.  Share and enjoy, and please try it out and
give us feedback.  Thanks,

Your friendly neighborhood JUnit maintainers

## Summary of Changes in version 4.9 [unreleased!] ##

Release theme: Test-class and suite level Rules.

### ClassRule ###

The `ClassRule` annotation extends the idea of method-level Rules,
adding static fields that can affect the operation of a whole class.  Any
subclass of `ParentRunner`, including the standard `BlockJUnit4ClassRunner`
and `Suite` classes, will support `ClassRule`s.

For example, here is a test suite that connects to a server once before
all the test classes run, and disconnects after they are finished:

	@RunWith(Suite.class)
	@SuiteClasses({A.class, B.class, C.class})
	public class UsesExternalResource {
		public static Server myServer= new Server();
	
		@ClassRule
		public static ExternalResource resource= new ExternalResource() {
			@Override
			protected void before() throws Throwable {
				myServer.connect();
			};
	
			@Override
			protected void after() {
				myServer.disconnect();
			};
		};
	}

### TestRule ###

In JUnit 4.9, fields that can be annotated with either `@Rule` or `@ClassRule`
should be of type `TestRule`.  The old `MethodRule` type, which only made sense
for method-level rules, will still work, but is deprecated.

Most built-in Rules have been moved to the new type already, in a way that
should be transparent to most users.  `TestWatchman` has been deprecated,
and replaced by `TestWatcher`, which has the same functionality, but implements
the new type.

### Maven support ###

Maven bundles have, in the past, been uploaded by kind volunteers.  Starting
with this release, the JUnit team is attempting to perform this task ourselves.

### LICENSE checked in ###

The Common Public License that JUnit is released under is now included
in the source repository.

### Bug fixes ###

- github#98: assumeTrue() does not work with expected exceptions
- github#74: Categories + Parameterized

  In JUnit 4.8.2, the Categories runner would fail to run correctly
  if any contained test class had a custom Runner with a structure
  significantly different from the built-in Runner.  With this fix,
  such classes can be assigned one or more categories at the class level,
  and will be run correctly.  Trying to assign categories to methods within
  such a class will flag an error.

- github#38: ParentRunner filters more than once

  Thanks to `@reinholdfuereder`

- github#248: protected BlockJUnit4ClassRunner#rules method removed from 4.8.2
- github#187: Accidental dependency on Java 6

Thanks to `@kcooney` for:

- github#163: Bad comparison failure message when using
assertEquals(String, String)
- github#227: ParentRunner now assumes that getChildren() returns a
modifiable list

### Minor changes ###

- Backed out unused folder "experimental-use-of-antunit", replaced by
  bash-based script at build_tests.sh
- Various Javadoc fixes

Thanks to `@kcooney` for:

- Made MultipleFailureException public, to assist extension writers.
- github#240: Add "test" target to build.xml, for faster ant-driven testing.
- github#247: Give InitializationError a useful message

Re: [Junit-devel] Adding @NonParameterized

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

On Tue, Jul 19, 2011 at 3:21 PM, Marius Kruger <am...@gm...> wrote:
> On 19 July 2011 20:56, David Saff <da...@sa...> wrote:
>> I've gotten a bit too buried in day work to fully answer this.
>
> yes I'm also busy, I understand.
>
>> Two points:
>>
>> 1) I've opened an issue on github, so this doesn't get lost:
>> https://github.com/KentBeck/junit/issues/264
>
> thanks
>
>> 2) Also, if you'd like to contribute a patched version of
>> Parameterized to the junit.contrib project, I'd be happy to work with
>> you on that.
>
> Sure, if you think it will be too long to wait for the other new features.
> Should I submit this somewhere else then?
> When you have time let me know what I need to fix to get it in, or
> point me to instructions somewhere.

I need to write up better instructions (since no one has actually
issued a junit.contrib pull request yet), but the idea is:

1) Fork http://github.com/dsaff/junit.contrib
2) Create a folder with your project name (nonparameterized?)
3) Put your work there, in a standard Maven source layout.
4) Put an Apache 2.0 license agreement in as a LICENSE file
5) Issue a pull request.

I'd be happy to work with you to resolve any confusion.  Thanks,

   David

>
> --
> <>< Marius ><>
>

Re: [Junit-devel] Adding @NonParameterized

[Marius K. <am...@gm...>]

On 19 July 2011 20:56, David Saff <da...@sa...> wrote:
> I've gotten a bit too buried in day work to fully answer this.

yes I'm also busy, I understand.

> Two points:
>
> 1) I've opened an issue on github, so this doesn't get lost:
> https://github.com/KentBeck/junit/issues/264

thanks

> 2) Also, if you'd like to contribute a patched version of
> Parameterized to the junit.contrib project, I'd be happy to work with
> you on that.

Sure, if you think it will be too long to wait for the other new features.
Should I submit this somewhere else then?
When you have time let me know what I need to fix to get it in, or
point me to instructions somewhere.

-- 
<>< Marius ><>

Re: [Junit-devel] Adding @NonParameterized

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

I've gotten a bit too buried in day work to fully answer this.  Two points:

1) I've opened an issue on github, so this doesn't get lost:
https://github.com/KentBeck/junit/issues/264
2) Also, if you'd like to contribute a patched version of
Parameterized to the junit.contrib project, I'd be happy to work with
you on that.

   David Saff

On Thu, Jul 14, 2011 at 3:29 PM, Marius Kruger <am...@gm...> wrote:
> On 27 June 2011 17:40, David Saff <da...@sa...> wrote:
>>
>> Good point.
>>
>> Here's how I'm thinking about moving forward: we currently have @Rule,
>> which provides a way to override the rules for _running_ a method, for
>> _every @Test_ method in the class.  I'm considering a similar
>> construct, which will allow overriding:
>>
>> 1) Which methods trigger tests
>> 2) How many tests per method
>> 3) Validation of test methods
>> 4) Test-instance creation
>> 5) Test-method invoking
>>
>> Given this, it should be possible to enable something very close to
>> @NonParameterized as a drop-in Rule-like object, rather than as a core
>> modification to the overall Parameterized runner.
>
> It's a bit abstract for me, I can not imagine/picture how my use case will
> look like with this. With the above features it sounds like it will be quite
> useful.
> If you like you can make a sudo example to show how you imagine it to be
> used.
>
>>
>> One issue: I can't think of a name for this new construct.  Suggestions
>> welcome.
>
> @TestController
> @TestOrchestrator
> @TestManager
>
> One problem that I noticed with @RunWith(JUnitParamsRunner.class) tests is
> that
> IDE support lags a bit or maybe its a bug, but from eclipse I can't re-run a
> single method or one of it's permutations or jump to its location by
> double-clicking on it in the junit panel. It works fine with @RunWith(value
> = Parameterized.class) which I'm glad to see.
> Before I knew about this, I made my own suite implementation to sort of do
> this,
> and with some tweaking I was able to get eclipse to be able to re-run those
> too.
> --
> <>< Marius ><>
>
>

Re: [Junit-devel] JUnit / Ant 1.8

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

Have you followed the directions under "This task depends on external
libraries not included in the Apache Ant distribution" at
http://ant.apache.org/manual/Tasks/junit.html?

Good luck,

   David Saff

On Thu, Jul 14, 2011 at 12:39 PM, shawn smith <une...@ho...> wrote:
> I am trying to get Junit 4 to run with Ant 1.8. I keep getting the same
> generic message when I run the build. "Could not create task or type of type
> : junit" I have my class path set up to access the junit jars. Anyone had
> similar error?
>
> .......
>
>
> <!-- JUnit properties -->
>
>  <property name="lib"
> value="C:\workspaces\ABADSLocalBuild\ProjectSource\source\published\classes"
> />
>
>
> <!-- Define the classpath which includes the junit.jar and the classes after
> compilling -->
>      <path id="junit.class.path">
>         <fileset dir="${lib}">
>             <include name="**\*.jar" />
>         </fileset>
>     </path>
>
> <target name="test" depends="package_web">
>     <junit>
>         <classpath refid="junit.class.path" />
>         <formatter type="plain" usefile="false" />
>         <test
> name="C:\workspaces\ABADSLocalBuild\ProjectSource\source\java\build\xyzjunWeb\com\highmark\xyzjun\test\SampleServletTest"
> />
>     </junit>
> </target>
>
> ........
>
> Greg
>
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>
>

Re: [Junit-devel] Feature request: @Name

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

Behrang,

Sorry for the long response delay.  This is an interesting idea.  You
should be able to try it out fairly easily:

1) Create your own subclass of BlockJUnit4ClassRunner that overrides
describeChild
2) Annotate your classes with @RunWith(MyRunner.class)

One thing to watch out for is whether your running infrastructure
(ant, maven, eclipse, etc.) is robust against spaces in test
descriptions.  If it works out for you, let's think about contributing
it to junit.contrib.  Thanks,

   David Saff

On Sat, Jul 9, 2011 at 7:38 PM, Behrang Saeedzadeh <beh...@gm...> wrote:
> Hi,
>
> I think it would be nice if there was an annotation for JUnit for
> naming annotations.
>
> Right now creating test cases with self explanatory names lead very
> long and ugly methods names, e.g.:
>
> @Test
> public void headingElementShouldNotBeResolvedWithoutNamespaceMapping() {
> }
>
> @Test
> public void headingElementShouldBeResolvedWithNamespaceMapping() {
> }
>
> It would be nice if we could have named the test case in an annotation, e.g.:
>
> @Test
> @Name("Heading Element Should Not Be Resolved Without Namespace Mapping")
> public void testResolution1() {
> }
>
> @Test
> @Name("Heading Element Should Be Resolved With Namespace Mapping")
> public void testResolution2() {
> }
>
> or maybe even:
>
> @Test(name = "Heading Element Should Not Be Resolve Without Namespace Mapping")
> public void testResolution1() {
> }
>
> @Test(name = "Heading Element Should Be Resolved With Namespace Mapping")
> public void testResolution2() {
> }
>
> Right now I have started using a similar annotation for my new
> projects, but had it been integrated with JUnit, it would have used
> the name in reporting errors, etc.
>
> A @Description element might also be useful for providing more details
> about a test.
>
> Cheers,
> Behrang Saeedzadeh
> http://www.behrang.org
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>

Re: [Junit-devel] Adding @NonParameterized

[Marius K. <am...@gm...>]

On 27 June 2011 17:40, David Saff <da...@sa...> wrote:

> Good point.
>
> Here's how I'm thinking about moving forward: we currently have @Rule,
> which provides a way to override the rules for _running_ a method, for
> _every @Test_ method in the class.  I'm considering a similar
> construct, which will allow overriding:
>
> 1) Which methods trigger tests
> 2) How many tests per method
> 3) Validation of test methods
> 4) Test-instance creation
> 5) Test-method invoking
>
> Given this, it should be possible to enable something very close to
> @NonParameterized as a drop-in Rule-like object, rather than as a core
> modification to the overall Parameterized runner.
>

It's a bit abstract for me, I can not imagine/picture how my use case will
look like with this. With the above features it sounds like it will be quite
useful.
If you like you can make a sudo example to show how you imagine it to be
used.


> One issue: I can't think of a name for this new construct.  Suggestions
> welcome.
>

@TestController
@TestOrchestrator
@TestManager


One problem that I noticed with @RunWith(JUnitParamsRunner.class) tests is
that
IDE support lags a bit or maybe its a bug, but from eclipse I can't re-run a
single method or one of it's permutations or jump to its location by
double-clicking on it in the junit panel. It works fine with @RunWith(value
= Parameterized.class) which I'm glad to see.
Before I knew about this, I made my own suite implementation to sort of do
this,
and with some tweaking I was able to get eclipse to be able to re-run those
too.

-- 
<>< Marius ><>

[Junit-devel] JUnit / Ant 1.8

[shawn s. <une...@ho...>]

I am trying to get Junit 4 to run with Ant 1.8. I keep getting the same generic message when I run the build. "Could not create task or type of type : junit" I have my class path set up to access the junit jars. Anyone had similar error?

.......


<!-- JUnit properties -->

 <property name="lib" value="C:\workspaces\ABADSLocalBuild\ProjectSource\source\published\classes" /> 


<!-- Define the classpath which includes the junit.jar and the classes after compilling -->
     <path id="junit.class.path">            
        <fileset dir="${lib}">
            <include name="**\*.jar" />
        </fileset>    
    </path> 

<target name="test" depends="package_web">
    <junit>
        <classpath refid="junit.class.path" />
        <formatter type="plain" usefile="false" />
        <test name="C:\workspaces\ABADSLocalBuild\ProjectSource\source\java\build\xyzjunWeb\com\highmark\xyzjun\test\SampleServletTest" />
    </junit>
</target>

........   

Greg
 		 	   		  

Re: [Junit-devel] assertThrows(myObject).methodCall()

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

Actually, junit.contrib will have the Apache license, so that won't be
a problem.  It may be a problem if we ever wanted to "promote" any of
the code into JUnit core, but the odds are we wouldn't, with the
external dependency, anyway.  Thanks,

   David

On Tue, Jul 12, 2011 at 1:50 AM, Thomas Mueller
<tho...@gm...> wrote:
> Hi,
>
> I started writing the class proxy generator. So far my code writes a
> <ClassName>Proxy.java file, which is then compiled (and loaded using a
> custom classloader). The source code detour works well and is simple
> (240 lines, http://code.google.com/p/h2database/source/browse/trunk/h2/src/test/org/h2/test/utils/ProxyCodeGenerator.java),
> but obviously requires a Java compiler (either the JDK, or the Eclipse
> compiler; by the way Javac 1.5 requires "method(..) throws
> *RuntimeException*" which is funny). The next step is to generate the
> bytecode directly.
>
> Would it be an option to re-use the Apache Harmony proxy generator
> source code? Not "as is", but as a starting point. JUnit is "Common
> Public License - v 1.0", is using the Apache license for this part an
> option? If not, I could implement the bytecode generator myself (from
> scratch), but that would be more work. Or I could search for another
> project with a better license.
>
> Regards,
> Thomas
>

Re: [Junit-devel] assertThrows(myObject).methodCall()

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

Your licensing question is a very good one.  I find I have to remind
myself anew of licensing issues each time I try to give a good
answer--I'll get back to you...

   David Saff

On Tue, Jul 12, 2011 at 2:50 AM, Thomas Mueller
<tho...@gm...> wrote:
> Hi,
>
> I started writing the class proxy generator. So far my code writes a
> <ClassName>Proxy.java file, which is then compiled (and loaded using a
> custom classloader). The source code detour works well and is simple
> (240 lines, http://code.google.com/p/h2database/source/browse/trunk/h2/src/test/org/h2/test/utils/ProxyCodeGenerator.java),
> but obviously requires a Java compiler (either the JDK, or the Eclipse
> compiler; by the way Javac 1.5 requires "method(..) throws
> *RuntimeException*" which is funny). The next step is to generate the
> bytecode directly.
>
> Would it be an option to re-use the Apache Harmony proxy generator
> source code? Not "as is", but as a starting point. JUnit is "Common
> Public License - v 1.0", is using the Apache license for this part an
> option? If not, I could implement the bytecode generator myself (from
> scratch), but that would be more work. Or I could search for another
> project with a better license.
>
> Regards,
> Thomas
>

Re: [Junit-devel] assertThrows(myObject).methodCall()

[Thomas M. <tho...@gm...>]

Hi,

I started writing the class proxy generator. So far my code writes a
<ClassName>Proxy.java file, which is then compiled (and loaded using a
custom classloader). The source code detour works well and is simple
(240 lines, http://code.google.com/p/h2database/source/browse/trunk/h2/src/test/org/h2/test/utils/ProxyCodeGenerator.java),
but obviously requires a Java compiler (either the JDK, or the Eclipse
compiler; by the way Javac 1.5 requires "method(..) throws
*RuntimeException*" which is funny). The next step is to generate the
bytecode directly.

Would it be an option to re-use the Apache Harmony proxy generator
source code? Not "as is", but as a starting point. JUnit is "Common
Public License - v 1.0", is using the Apache license for this part an
option? If not, I could implement the bytecode generator myself (from
scratch), but that would be more work. Or I could search for another
project with a better license.

Regards,
Thomas

[Junit-devel] Feature request: @Name

[Behrang S. <beh...@gm...>]

Hi,

I think it would be nice if there was an annotation for JUnit for
naming annotations.

Right now creating test cases with self explanatory names lead very
long and ugly methods names, e.g.:

@Test
public void headingElementShouldNotBeResolvedWithoutNamespaceMapping() {
}

@Test
public void headingElementShouldBeResolvedWithNamespaceMapping() {
}

It would be nice if we could have named the test case in an annotation, e.g.:

@Test
@Name("Heading Element Should Not Be Resolved Without Namespace Mapping")
public void testResolution1() {
}

@Test
@Name("Heading Element Should Be Resolved With Namespace Mapping")
public void testResolution2() {
}

or maybe even:

@Test(name = "Heading Element Should Not Be Resolve Without Namespace Mapping")
public void testResolution1() {
}

@Test(name = "Heading Element Should Be Resolved With Namespace Mapping")
public void testResolution2() {
}

Right now I have started using a similar annotation for my new
projects, but had it been integrated with JUnit, it would have used
the name in reporting errors, etc.

A @Description element might also be useful for providing more details
about a test.

Cheers,
Behrang Saeedzadeh
http://www.behrang.org

[Junit-devel] AUTO: Fran Hughes is out of the office today (returning 20/07/2011)

[Fran H. <fra...@ie...>]

I am out of the office until 20/07/2011.

I will have no access to email/voice mail during this time.
If your email is regarding an existing PMR, please contact
the IBM ECM Support via contact numbers as listed in
http://www.ibm.com/planetwide.
Otherwise I will respond to your message when I return.
If you have an urgent question relating to an issue please contact
the FRC via the hotline and request to speak directly to
my Technical Manager Pick One of the following:

Hannu Lindroos (hli...@ie...).
Douglas Good (dou...@ie...).
Damien Sinardet (Dam...@ie...)

With kind regards,

Fran Hughes


Note: This is an automated response to your message  "Junit-devel Digest,
Vol 32, Issue 1" sent on 8/7/11 10:26:03.

This is the only notification you will receive while this person is away.

Re: [Junit-devel] assertThrows(myObject).methodCall()

[Thomas M. <tho...@gm...>]

Hi,

> No, we're unlikely to include it in base JUnit, because the reflection
> magic is likely to not work on all platforms that JUnit currently
> works on, and, as you point out, it won't work on final classes, or
> any classes without CGLIB, etc.

I understand. Well, java.lang.reflect.Proxy is supposed to run
everywhere, but it does make sense to try it out in an experimental
project.

> However, it's an absolutely perfect idea for junit.contrib, the
> companion project for experimental code, which I'm trying to get off
> the ground.  The submission process to junit.contrib is still
> relatively undefined (which is why there's no code there yet).  Would
> you be interested in being a charter contributor?

Sure. You need to tell me what the directory structure and so on is
supposed to look like.

I can write a patch for assertThrows as it is now (to support
interfaces only; without any bytecode manipulation), together with
some documentation. That alone solves 90% of the problem.
Non-interface methods will require more work. I'm not sure if it makes
sense to "role your own" bytecode generation, or depend one of the
existing libraries (bcel, asm, cglib). It sounds like what
assertThrows needs is a small subset of what those tool can do. I do
have a little bit of experience with bytecode (re-construct the source
code from the bytecode for my JaQu tool -
http://www.h2database.com/html/jaqu.html) and will try, but I can't
promise much. With this, you are at 98%. Still remaining are static
methods and final classes. This is even more complicated, but maybe
there is a way - see http://code.google.com/p/powermock/ and
http://projectlombok.org/

To make the method sound less weird, I would document it as follows:

Object assertThrows(Object o)
Creates a verifying proxy for an object, which checks each method call
throws an exception. Example:

// Wrap the object into a proxy
List proxyList = assertThrows(myList);

// This will internally call myList.get(0) and verify it throws an exception.
// If it doesn't throw an exception, then the proxy calls Assert.fail().
proxyList.get(0);

// Simplified usage
assertThrows(myList).get(0);

--------------------

Then, what about:

// check the method call is relatively fast / slow
assertFast([maxMillis,] myObject).myMethod()
assertSlow([maxMillis,] myObject).myMethod()

I don't have a use case for those, but probably others.

// call the method in a loop (with a 10 ms delay) until it returns the
expected result
assertEventuallyTrue([maxMillis,] myObject).myMethod()
assertEventuallyFalse([maxMillis,] myObject).myMethod()

I do have an actual use case for assertEventuallyTrue/False: my
program is supposed to delete files in a background thread within some
non-deterministic time. And I don't want to use Thread.sleep(..)
because it slows down testing unnecessarily (usually, the thread is
quick).

Regards,
Thomas

Re: [Junit-devel] assertThrows(myObject).methodCall()

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

Thomas,

Yes, this feature is awesome.

No, we're unlikely to include it in base JUnit, because the reflection
magic is likely to not work on all platforms that JUnit currently
works on, and, as you point out, it won't work on final classes, or
any classes without CGLIB, etc.

However, it's an absolutely perfect idea for junit.contrib, the
companion project for experimental code, which I'm trying to get off
the ground.  The submission process to junit.contrib is still
relatively undefined (which is why there's no code there yet).  Would
you be interested in being a charter contributor?

   David Saff

On Thu, Jul 7, 2011 at 4:10 PM, Thomas Mueller
<tho...@gm...> wrote:
> Hi,
>
> I have many test cases that expect an exception to be thrown. I want
> to verify that a given method of my code will actually throw an
> exception in a given test case. What I want is described here:
> http://stackoverflow.com/questions/156503/how-to-assert-that-a-certain-exception-is-thrown-in-junit4-5-tests
> - Example (please not my actual use case isn't ArrayList - this is
> just an example):
>
> List<String> myObject = new ArrayList<String>();
>
> // current pattern - 6 lines of code
> try {
>   myObject.get(0);
>   fail();
> } catch (IndexOutOfBoundsException e) {
>   // expected
> }
>
> Now, I have a few problems with this. First, it's 6 lines of code,
> which is a lot. Then, it's too easy to forget 'fail()' (I forgot it in
> many cases). I know I could refactor the test to move it to a separate
> method, and add @Test(expected=IndexOutOfBoundsException.class) (the
> top answer on StackOverflow) - but that's ugly as well. I don't _want_
> a separate test method.
>
> I found a solution to simplify the test, by creating a new helper
> method 'assertThrows' (implementation below), so that my test case is
> now:
>
> // shorter, 1 line
> assertThrows(IndexOutOfBoundsException.class, myObject).get(0);
>
> // even shorter (if I don't care what kind of exception)
> assertThrows(myObject).get(0);
>
> My solution currently uses a Java proxy (which obviously only works
> for interfaces), but using CGLIB it would be possible to support
> (non-final) regular classes as well. Anyway, for reference, my
> solution is here:
> http://h2database.com/p.html#554bf1f041969cba0f6fa1a6e8e20cba - my
> solution checks that a method was called by miss-using finalize, which
> is OK for my use case (there are probably better solutions for this).
>
> I know there are other solutions. I do know this has been discussed
> before on the JUnit list:
> http://old.nabble.com/assertNotEquals-and-assertThrows-td3423551.html
>
> I also know that JUnit 4.7+ has "Rules" but I really don't want to
> write one method for each test. It's ugly because it forces me to
> split a test into many tiny methods. I don't like this. For example, I
> have test code like this:
>
> assertThrows(stat).execute("select sum(id) from test for update");
> assertThrows(stat).execute("select distinct id from test for update");
> assertThrows(stat).execute("select id from test group by id for update");
> assertThrows(stat).execute("select t1.id from test t1, test t2 for update");
>
> Every *line* would have to be in it's own method.
>
> I have the feeling my feature request will reject it because it would
> force JUnit to include a proxy mechanism like CGLIB (which I guess
> isn't included now; maybe I'm wrong). And you will probably it's a bit
> hacky (well, it is). But it *is* very useful (at least in my view).
>
> I have already submitted this request to Mockito, but they are not
> interested that much - they wrote this feature is something that JUnit
> is supposed support, as it's not that much related to what Mockito
> does.
>
> So, what do you think?
>
> Regards,
> Thomas
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>

[Junit-devel] assertThrows(myObject).methodCall()

[Thomas M. <tho...@gm...>]

Hi,

I have many test cases that expect an exception to be thrown. I want
to verify that a given method of my code will actually throw an
exception in a given test case. What I want is described here:
http://stackoverflow.com/questions/156503/how-to-assert-that-a-certain-exception-is-thrown-in-junit4-5-tests
- Example (please not my actual use case isn't ArrayList - this is
just an example):

List<String> myObject = new ArrayList<String>();

// current pattern - 6 lines of code
try {
   myObject.get(0);
   fail();
} catch (IndexOutOfBoundsException e) {
   // expected
}

Now, I have a few problems with this. First, it's 6 lines of code,
which is a lot. Then, it's too easy to forget 'fail()' (I forgot it in
many cases). I know I could refactor the test to move it to a separate
method, and add @Test(expected=IndexOutOfBoundsException.class) (the
top answer on StackOverflow) - but that's ugly as well. I don't _want_
a separate test method.

I found a solution to simplify the test, by creating a new helper
method 'assertThrows' (implementation below), so that my test case is
now:

// shorter, 1 line
assertThrows(IndexOutOfBoundsException.class, myObject).get(0);

// even shorter (if I don't care what kind of exception)
assertThrows(myObject).get(0);

My solution currently uses a Java proxy (which obviously only works
for interfaces), but using CGLIB it would be possible to support
(non-final) regular classes as well. Anyway, for reference, my
solution is here:
http://h2database.com/p.html#554bf1f041969cba0f6fa1a6e8e20cba - my
solution checks that a method was called by miss-using finalize, which
is OK for my use case (there are probably better solutions for this).

I know there are other solutions. I do know this has been discussed
before on the JUnit list:
http://old.nabble.com/assertNotEquals-and-assertThrows-td3423551.html

I also know that JUnit 4.7+ has "Rules" but I really don't want to
write one method for each test. It's ugly because it forces me to
split a test into many tiny methods. I don't like this. For example, I
have test code like this:

assertThrows(stat).execute("select sum(id) from test for update");
assertThrows(stat).execute("select distinct id from test for update");
assertThrows(stat).execute("select id from test group by id for update");
assertThrows(stat).execute("select t1.id from test t1, test t2 for update");

Every *line* would have to be in it's own method.

I have the feeling my feature request will reject it because it would
force JUnit to include a proxy mechanism like CGLIB (which I guess
isn't included now; maybe I'm wrong). And you will probably it's a bit
hacky (well, it is). But it *is* very useful (at least in my view).

I have already submitted this request to Mockito, but they are not
interested that much - they wrote this feature is something that JUnit
is supposed support, as it's not that much related to what Mockito
does.

So, what do you think?

Regards,
Thomas

[Junit-devel] JUnit 4.9b3 (finally) (beta-)released

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

Five months and a dozen regression errors later, JUnit 4.9b3 is now
ready for your testing pleasure. This release's theme is Test-class
and suite level Rules.  For details and links, please see:

http://saffgreenbar.blogspot.com/2011/07/junit-49b3-beta-released.html

Thanks to everyone for the feedback and patches.  If no further
regressions are found in the next week, this release will go final.

   David Saff

Re: [Junit-devel] Adding @NonParameterized

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

Good point.

Here's how I'm thinking about moving forward: we currently have @Rule,
which provides a way to override the rules for _running_ a method, for
_every @Test_ method in the class.  I'm considering a similar
construct, which will allow overriding:

1) Which methods trigger tests
2) How many tests per method
3) Validation of test methods
4) Test-instance creation
5) Test-method invoking

Given this, it should be possible to enable something very close to
@NonParameterized as a drop-in Rule-like object, rather than as a core
modification to the overall Parameterized runner.

One issue: I can't think of a name for this new construct.  Suggestions welcome.

   David Saff

On Sat, Jun 25, 2011 at 4:11 PM, Marius Kruger <am...@gm...> wrote:
> On 25 June 2011 21:19, Marius Kruger <am...@gm...> wrote:
>> On 20 June 2011 21:57, David Saff <da...@sa...> wrote:
>> ...
>>> Parameterized.class currently allows one parameterization per test
>>> class.  This patch enables two parameterizations, one of which must be
>>> the special case of "no parameters".  A runner like JUnitParams
>>> (http://code.google.com/p/junitparams/) enables an arbitrary number of
>>> parameterizations, including "no parameters".  I'd like to consider
>>> how to handle the arbitrary case, like JUnitParams, and would rather
>>> not create a special case for "no parameters" that users would need to
>>> migrate to the new framework when it's ready.
>>>
>>> Does that make sense?
>>
>> Yes now that I looked at JUnitParams. It is awesome - much more than I
>> needed so far.
>
> I now found a case that was handled much nicer with my patched version:
> I just want to setUp(@Before) the tests according to a parameter. This
> is possible with the standard JUnit Parameterized runner and my
> version because we get the value in the constructor. eg.:
>
> A)==
> @RunWith(JUnitParamsRunner.class)
> public class MyJUnitParamsTest {
>
>    protected AbstractHomeLayout homeLayout;
>
>    public void setupHomeLayout(int layoutVersion) {
>        homeLayout = init(layoutVersion);
>    }
>
>    protected Object[] getLayoutVersions() {
>      return new Object[][] { { 0 }, { 1 } };
>    }
>
>    @Test
>    @Parameters(method = "getLayoutVersions")
>    public void testParameterized(int layoutVersion) throws IOException {
>        setupHomeLayout(layoutVersion);
>        //test stuff
>    }
>
>    @Test
>    public void testNonParameterized() throws IOException {
>        //test stuff
>    }
>
>   // 10 more tests like these
> }
> ==
>
> B)==
> @RunWith(value = Parameterized.class)
> public class MyParameterizedTest {
>
>    int layoutVersion
>    public HomeLayoutTest(int layoutVersion) {
>         this.layoutVersion = layoutVersion;
>    }
>
>    protected AbstractHomeLayout homeLayout;
>
>    @Before
>    public void setupHomeLayout() {
>        homeLayout = init(layoutVersion);
>    }
>
>    @Parameters
>    public static Collection getLayoutVersions() {
>      Object[][] data = new Object[][] { { 0 }, { 1 } };
>      return Arrays.asList(data);
>    }
>
>    @Test
>    public void testParameterized() throws IOException {
>        setupHomeLayout(layoutVersion);
>        //test stuff
>    }
>
>    @Test
>    @NonParameterized
>    public void testNonParameterized() throws IOException {
>        //test stuff
>    }
>
>   // 10 more tests like these
> }
> ==
>
>
> So with A you have to modify three lines for every single parameterized test:
> @Parameters(method = "getLayoutVersions")
>    public void testParameterized(int layoutVersion) throws IOException {
>        setupHomeLayout(layoutVersion);
> but in B you just annotate the non-parameterized tests...
>
>
>
> --
> <>< Marius ><>
>

Re: [Junit-devel] Adding @NonParameterized

[Marius K. <am...@gm...>]

On 25 June 2011 21:19, Marius Kruger <am...@gm...> wrote:
> On 20 June 2011 21:57, David Saff <da...@sa...> wrote:
> ...
>> Parameterized.class currently allows one parameterization per test
>> class.  This patch enables two parameterizations, one of which must be
>> the special case of "no parameters".  A runner like JUnitParams
>> (http://code.google.com/p/junitparams/) enables an arbitrary number of
>> parameterizations, including "no parameters".  I'd like to consider
>> how to handle the arbitrary case, like JUnitParams, and would rather
>> not create a special case for "no parameters" that users would need to
>> migrate to the new framework when it's ready.
>>
>> Does that make sense?
>
> Yes now that I looked at JUnitParams. It is awesome - much more than I
> needed so far.

I now found a case that was handled much nicer with my patched version:
I just want to setUp(@Before) the tests according to a parameter. This
is possible with the standard JUnit Parameterized runner and my
version because we get the value in the constructor. eg.:

A)==
@RunWith(JUnitParamsRunner.class)
public class MyJUnitParamsTest {

    protected AbstractHomeLayout homeLayout;

    public void setupHomeLayout(int layoutVersion) {
        homeLayout = init(layoutVersion);
    }

    protected Object[] getLayoutVersions() {
      return new Object[][] { { 0 }, { 1 } };
    }

    @Test
    @Parameters(method = "getLayoutVersions")
    public void testParameterized(int layoutVersion) throws IOException {
        setupHomeLayout(layoutVersion);
        //test stuff
    }

    @Test
    public void testNonParameterized() throws IOException {
        //test stuff
    }

   // 10 more tests like these
}
==

B)==
@RunWith(value = Parameterized.class)
public class MyParameterizedTest {

    int layoutVersion
    public HomeLayoutTest(int layoutVersion) {
         this.layoutVersion = layoutVersion;
    }

    protected AbstractHomeLayout homeLayout;

    @Before
    public void setupHomeLayout() {
        homeLayout = init(layoutVersion);
    }

    @Parameters
    public static Collection getLayoutVersions() {
      Object[][] data = new Object[][] { { 0 }, { 1 } };
      return Arrays.asList(data);
    }

    @Test
    public void testParameterized() throws IOException {
        setupHomeLayout(layoutVersion);
        //test stuff
    }

    @Test
    @NonParameterized
    public void testNonParameterized() throws IOException {
        //test stuff
    }

   // 10 more tests like these
}
==


So with A you have to modify three lines for every single parameterized test:
@Parameters(method = "getLayoutVersions")
    public void testParameterized(int layoutVersion) throws IOException {
        setupHomeLayout(layoutVersion);
but in B you just annotate the non-parameterized tests...



-- 
<>< Marius ><>

Re: [Junit-devel] Adding @NonParameterized

[Marius K. <am...@gm...>]

On 20 June 2011 21:57, David Saff <da...@sa...> wrote:
...
> Parameterized.class currently allows one parameterization per test
> class.  This patch enables two parameterizations, one of which must be
> the special case of "no parameters".  A runner like JUnitParams
> (http://code.google.com/p/junitparams/) enables an arbitrary number of
> parameterizations, including "no parameters".  I'd like to consider
> how to handle the arbitrary case, like JUnitParams, and would rather
> not create a special case for "no parameters" that users would need to
> migrate to the new framework when it's ready.
>
> Does that make sense?

Yes now that I looked at JUnitParams. It is awesome - much more than I
needed so far.
I'll be using that then in the mean time.
Thanks a lot for pointing me this way.

-- 
sorry for the late reply, it was a busy week.
<>< Marius ><>

Re: [Junit-devel] Adding @NonParameterized

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

On Fri, Jun 17, 2011 at 4:19 PM, Marius Kruger <am...@gm...> wrote:
> On 16 June 2011 16:45, David Saff <da...@sa...> wrote:
>> Marius,
>>
>> Thanks, now I understand where this is going.  Genuinely sorry for the
>> git busywork.  I still don't know why the attachments aren't getting
>> passed along.
>
> They were probably just a little too big and needed moderation. That's
> why I mailed it to you directly too.
>
>> As to the feature itself, I'm confused--what's the cost of moving the
>> non-parameterized tests to their own class?  You can also use
>> @RunWith(Enclosed.class) to have several inner classes, with different
>> parameterizations, inside one file.
>
> In short that is not how I'd like to use it, is there any reason why
> you don't want this feature?

Parameterized.class currently allows one parameterization per test
class.  This patch enables two parameterizations, one of which must be
the special case of "no parameters".  A runner like JUnitParams
(http://code.google.com/p/junitparams/) enables an arbitrary number of
parameterizations, including "no parameters".  I'd like to consider
how to handle the arbitrary case, like JUnitParams, and would rather
not create a special case for "no parameters" that users would need to
migrate to the new framework when it's ready.

Does that make sense?

   David Saff


> I like to group tests that test the same functionality and require the
> same setup in the same class.
> So if it makes sense for some tests to run several times and some only once
> and they all use the same setup, I'd like them in one class.
> If there are one or two tests that does not need to execute multiple
> times then I'll rather let them
> execute multiple times than split them out into their own class
> because they belong with the others.
> But if it is easy to mark them to not execute multiple times then I
> want to do that.
> Multiple nested classes will be much uglier than a simple annotation, IMHO.
> The first 3 classes that I wanted to use Parameterized on I also
> wanted partially @NonParameterized.
> I'd really rather have this in the core of junit in stead of
> maintaining my own junit utils elsewhere.
>
> --
> thanks for listening :-)
> <>< Marius ><>
>

Re: [Junit-devel] Adding @NonParameterized

[Marius K. <am...@gm...>]

On 16 June 2011 16:45, David Saff <da...@sa...> wrote:
> Marius,
>
> Thanks, now I understand where this is going.  Genuinely sorry for the
> git busywork.  I still don't know why the attachments aren't getting
> passed along.

They were probably just a little too big and needed moderation. That's
why I mailed it to you directly too.

> As to the feature itself, I'm confused--what's the cost of moving the
> non-parameterized tests to their own class?  You can also use
> @RunWith(Enclosed.class) to have several inner classes, with different
> parameterizations, inside one file.

In short that is not how I'd like to use it, is there any reason why
you don't want this feature?

I like to group tests that test the same functionality and require the
same setup in the same class.
So if it makes sense for some tests to run several times and some only once
and they all use the same setup, I'd like them in one class.
If there are one or two tests that does not need to execute multiple
times then I'll rather let them
execute multiple times than split them out into their own class
because they belong with the others.
But if it is easy to mark them to not execute multiple times then I
want to do that.
Multiple nested classes will be much uglier than a simple annotation, IMHO.
The first 3 classes that I wanted to use Parameterized on I also
wanted partially @NonParameterized.
I'd really rather have this in the core of junit in stead of
maintaining my own junit utils elsewhere.

-- 
thanks for listening :-)
<>< Marius ><>

Re: [Junit-devel] Adding @NonParameterized

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

Marius,

Thanks, now I understand where this is going.  Genuinely sorry for the
git busywork.  I still don't know why the attachments aren't getting
passed along.

As to the feature itself, I'm confused--what's the cost of moving the
non-parameterized tests to their own class?  You can also use
@RunWith(Enclosed.class) to have several inner classes, with different
parameterizations, inside one file.

   David Saff


On Tue, Jun 14, 2011 at 7:18 PM, Marius Kruger <am...@gm...> wrote:
> On 14 June 2011 15:59, David Saff <da...@sa...> wrote:
>> How hard would it be to open this up as a github branch?
>
> I'm a bazaar guy so I first had to figure out this github thing first.
> I pushed my bazaar branches to github now:
> https://am...@gi.../amanica/junit-nonparameterized.git
> https://am...@gi.../amanica/nonparameterized_noparams.git
> (this only include the maven projects not the eclipse stuff)
>
> I don't know how to push different branches into the same git repo (I
> could not even fork it), so I just made separate repos:(
> Would it have been ok if I pushed it into launchpad instead?
>
> --
> <>< Marius ><>
>

Re: [Junit-devel] Adding @NonParameterized

[Marius K. <am...@gm...>]

On 14 June 2011 15:59, David Saff <da...@sa...> wrote:
> How hard would it be to open this up as a github branch?

I'm a bazaar guy so I first had to figure out this github thing first.
I pushed my bazaar branches to github now:
https://am...@gi.../amanica/junit-nonparameterized.git
https://am...@gi.../amanica/nonparameterized_noparams.git
(this only include the maven projects not the eclipse stuff)

I don't know how to push different branches into the same git repo (I
could not even fork it), so I just made separate repos:(
Would it have been ok if I pushed it into launchpad instead?

-- 
<>< Marius ><>