junit-devel — junit developers

[Junit-devel] can you please unsubscribe me

[Sergiu I. <ser...@gm...>]

Thank you!

Re: [Junit-devel] Adding @NonParameterized

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

Marius,

How hard would it be to open this up as a github branch?  Each time I
want to view one of your attachments, I end up having to go to the
web-based list archives and dig it up again.  I'm not sure why your
attachments aren't coming through.  If you're familiar with git, and
it wouldn't be too hard to have the discussion there, it would be
great.  Otherwise, we'll continue here, but more slowly.

   David

On Tue, Jun 14, 2011 at 8:16 AM, Marius Kruger <am...@gm...> wrote:
> On 13 June 2011 21:25, David Saff <da...@sa...> wrote:
>> Would it be possible to quickly code up a test showing the new runner
>> in action?  Thanks,
>
> I've attached a simple maven (and eclipse) project that uses this.
> Testing that it works with and without parameterized tests.
>
> Note that at the moment non-parameterized tests will be runned only
> once with the first parameter and only if there is at least one
> parameter.
> It may be possible to change this to always run but then it will need
> 2 constructors and thus I need to modify that validation too.
>
> --
> <>< Marius ><>
>

Re: [Junit-devel] Adding @NonParameterized

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

Would it be possible to quickly code up a test showing the new runner
in action?  Thanks,

   David

On Fri, Jun 10, 2011 at 7:56 PM, Marius Kruger <am...@gm...> wrote:
> Hi,
> I've just discovered and fell in love with Parameterized tests (with:
> @RunWith(value = Parameterized.class) )
>
> However in the first two use cases I have I have tests that does not
> use the parameterization
> mixed in with test that do use it (in the same class).
> I don't seem to be the only one missing this feature:
> http://stackoverflow.com/q/3361239/381083
>
> It appears that TestNG does not suffer from this problem.
> http://techinsides.blogspot.com/2010/09/dont-tie-yourself-up-parameterized.html
>
> I'm not so desperate to switch to TestNG, so I modified the builtin
> Parameterized class to support this feature (see attached).
> Just annotate applicable tests as @NonParameterized. Note that this
> class only works with its on annotations, i.e. check your imports.
>
> If this has any chance of getting merged into junit I can turn it into
> a branch add tests and documentation etc. let me know.
>
> --
> regards
> <>< Marius ><>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>
>

Re: [Junit-devel] Adding @NonParameterized

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

Here is a version with improved validation and error handling.

[Junit-devel] Adding @NonParameterized

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

Hi,
I've just discovered and fell in love with Parameterized tests (with:
@RunWith(value = Parameterized.class) )

However in the first two use cases I have I have tests that does not
use the parameterization
mixed in with test that do use it (in the same class).
I don't seem to be the only one missing this feature:
http://stackoverflow.com/q/3361239/381083

It appears that TestNG does not suffer from this problem.
http://techinsides.blogspot.com/2010/09/dont-tie-yourself-up-parameterized.html

I'm not so desperate to switch to TestNG, so I modified the builtin
Parameterized class to support this feature (see attached).
Just annotate applicable tests as @NonParameterized. Note that this
class only works with its on annotations, i.e. check your imports.

If this has any chance of getting merged into junit I can turn it into
a branch add tests and documentation etc. let me know.

--
regards
<>< Marius ><>

[Junit-devel] Github has stopped displaying vote counts...

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

All,

I've got good news and bad news.  The good news is that GitHub has
released Issues 2.0, which, among other things, fixes the sorting
options in the issues display, among other goodies.  The bad news is
that they've not only removed the ability to vote on bugs, they've
eliminated the ability to display or sort by existing votes.  As you
may know, I was using votes as a way of prioritizing future
development (and was getting excited about getting to the end of our
recent round of red tape, so we could start closing more of them
down!)

I currently have a request in to github to at least let us know what
the final count was.  Moving forward, it seems that the new interface
can sort by comment count.  I'll probably use that as a proxy for
community interest (feel free to make simple "+1" comments if you feel
the need) for the time being, but I'm open to other suggestions.

Thanks,

   David Saff

Re: [Junit-devel] How test classes specified in @Suite.SuiteClasses() will be executed.Test classes are executed in the order we specify in @Suite.SuiteClasses?????

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

Yes.

ju...@ya... is the more appropriate place to send questions
about usage.

   David Saff

On Fri, Apr 1, 2011 at 6:59 AM, Sreedhar A <asr...@gm...> wrote:
>
>
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself;
> WebMatrix provides all the features you need to develop and
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
>
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>
>

[Junit-devel] Is there is any way i can specify the order in which the test methods will be executed????

[Sreedhar A <asr...@gm...>]

[Junit-devel] How test classes specified in @Suite.SuiteClasses() will be executed.Test classes are executed in the order we specify in @Suite.SuiteClasses?????

[Sreedhar A <asr...@gm...>]

[Junit-devel] Structure of junit.contrib

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

All,

As you may have heard, I'm planning to start a junit.contrib project.
In this mail, I'll first review the reasons for such a project, and
secondly, I have a proposal for its structure, and I'd like feedback.

=== BACKGROUND: REASONS FOR junit.contrib ===

JUnit has always officially strived to be "the intersection of all
useful Java testing frameworks".  Thus, the goals for code that gets
into the junit repository include that it should:

1) Minimize dependencies on external libraries or particular JDK
versions beyond a widely-used minimum.
2) Be very unlikely to change API moving forward.
3) Emphasize opportunities for extension over the richness of core features.
4) Have potential usefulness to all Java developers, regardless of
their application domain.
5) Match in style to the current JUnit codebase.

Many people have made JUnit extensions that would be useful to a
healthy portion of Java developers, but do not meet all of the above
criteria.  For example, the extension may target a particular IDE, or
data that is stored in a SQL database, or in XML, or it may be
experimental, and likely to change API, or it may require an external
dependency.  Also, as the popularity of non-Java languages on the JVM
has grown, some people have made extensions to JUnit that make it
easier to use JUnit's core functionality in ways idiomatic to those
other languages.

It has always been an option for developers of these extensions to
publish them on their own repositories.  However, having a central
clearing-house as an option for extension developers has some
advantages, including discoverability, documentation, and dependency
management.

The goal is for junit.contrib (just started on
https://github.com/dsaff/junit.contrib) to be this clearing house.
All Java classes in this project should be in packages prefixed with
org.junit.contrib.

Now, the

=== PROPOSAL ===

The root structure of the project will contain:

/
  README
  docs/
  java/
  scala/ [?]
  clojure/ [?]

Thus, a folder for overall documentation, and then a folder
per-language.  I haven't thought about how non-java language
extensions should be organized.

Under java, there should be a folder per "subproject" (names chosen,
with apologies, by http://en.wikipedia.org/wiki/Special:Random):

java/
  brewmasters/
  callisto/
  hekler/
  norway/
  ...

Each subproject should be organized as its own maven project:

java/brewmasters/
  pom.xml
  src/main/java/org/junit/contrib/brewmasters/...
  src/test/java/org/junit/contrib/brewmasters/...

As potential users and contributors to such a repository, are there
pitfalls in this organization that I should be aware of in advance?
Thanks,

   David Saff

[Junit-devel] Is Junit good enough for web application testing(server code in java)

[Jyotirmoy S. <sun...@gm...>]

Hi Seniors,
 I am a newbie in using Junit. Please let me know if JUnit will be
good enough for web application  testing(server code in java). Is it
true that "The JUnit code will be complex and hard to maintain. You
will have to reproduce all of the interactions between code and user
within the Junit test, which very quickly becomes complex. If all you
are doing is testing one single entry point, then this could well
work, but if you are testing multiple screens (a wizard or something
like that), then it can quickly become fragile and unmanageable."?


I will be moving to watij if Junit is not good enough for web app
testing. Suggestions cordially invited.

--
Thanks and Regards
Jyotirmoy Sundi
-- 
Thanks and Regards
Jyotirmoy Sundi

[Junit-devel] Progress on JUnit issues...

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

All,

Over the last week or so, I've triaged almost 200 JUnit issues that
have accumulated over the last year, closing about 80 truly invalid
issues that were fixed, duplicates, or no longer made sense. I tagged
the rest with:
- regression bugs (9): there was an implementation of the feature that
worked prior to the 4.9 beta (although potentially earlier than
4.8.x))
- nonregression bugs (15): it is likely the feature has always failed
in the documented way.
- features (~95): additions to the (implicit) spec, with
implementations to provide the additions.

Thanks to everyone who has been submitting problems, proposals, and
patches.  I'm sorry that some of you have been waiting so long for a
response.

The next part of the development plan, in order:

- Fix the regression bugs
- Release a 4.9 beta 3
- Hopefully 4.9b3 can become the final release.  (I am not planning
any nonregression bug fixes or new features to get into the 4.9
release.  We need to steer this ship back toward frequent releases.)
- Create a github project for junit.contrib.
- Go through the backlog of pull requests, to see which can be
accepted as is, and which either need changes, or should be redirected
into junit.contrib.
- Work through non-regression bugs for further releases in the 4.9.x series
- Choose a number of highly-rated feature requests to be the scope for
4.10, and begin (patch acceptance / implementation)

I'm excited to see this project keep moving forward,

   David Saff

[Junit-devel] JUnit issue responsiveness (was: Re: [junit] Re: Misc improvements)

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

Marc,

In your position, I'd be frustrated, too.  I'll respond to the direct
situation on the original thread, but I wanted to talk here about the
larger context.

For those not aware of the context of Marc's comment, the
highest-voted issue on github is now over a year old, and there are
140 open issues.  By reducing the time to resolve issues, we wouldn't
lose the effort of motivated developers like Marc.

Here's a first couple of steps.

1) For several years now, issue triage and patch acceptance has been
one of several priorities that have competed for time during pair
programming sessions between the developers.  One benefit was that the
project didn't get away from either of us, and we were able to
evaluate proposed changes from multiple perspectives.  I'm going to
try taking solo point on these activities, with Kent as advisor.  Give
me a couple months to get a routine going, and then let me know if the
project seems like a more appealing place to contribute.

2) As part of this, I'll try to provide feedback within a week on new
issues and patches.  This may mean that feature requests we are
unlikely to incorporate will get closed quickly, rather than left open
and abandoned.  Let me know if it starts feeling like too much
pushback.

While this will apply to new issues and patches, there's still a
backlog to get through.  I can't estimate how quickly I'll be able to
get through it, nor am I sure in advance whether I will prioritize the
communication backlog above all new development activities.  If you've
read this far, and would like to bump your issue or patch up in the
queue with a reminder message, I should see it.

JUnit will likely continue to grow more slowly than your average open
source project.  This has had advantages in maintaining a coherent
core of concepts and limited churn in the core.  There are things like
reporting and data parsing that the core junit.jar file is unlikely to
ever do, as it strives to be "the intersection of all useful test
frameworks, not their union".  The Runners and Rules included in
junit.jar have always been intended as examples and starting points
for further extension outside of the core.

I think there could be value in a bundling of JUnitUnion: the JUnit
Core, plus a set of very useful and reusable extensions managed by
people outside the core JUnit team.  I'd love suggestions on the
technical and managerial ways such a super-package could be maintained
and distributed.

Thanks for sticking around.  Share and Enjoy.

   David Saff

On Mon, Feb 14, 2011 at 3:47 AM, mguillemot <mgu...@ya...> wrote:
> Hi David,
>
> not really the most motivating answer :-(
>
> Providing a clean patch requires time. I follow JUnit GitHub issues since long enough to have an idea of what happens there, therefore I will use my time for other activities.
>
> Cheers,
> Marc.
>
>
> --- In ju...@ya..., David Saff <david@...> wrote:
>>
>> Marc,
>>
>> After the release of 4.9 (hopefully soon), my plan is to concentrate
>> development and patching activity on GitHub issues with high vote
>> counts.  I recommend posting these as GitHub issues
>> (http://github.com/KentBeck/junit/issues)--feel free to use this forum
>> to encourage votes.  Thanks,
>>
>>    David Saff
>>
>> On Thu, Feb 10, 2011 at 12:09 PM, mguillemot <mguillemot@...> wrote:
>> > Hi,
>> >
>> > I would be interested to know if JUnit team would have interest in the features below for integration in JUnit. If yes, I would look at providing patches and if not, I'll find an other way to waste my time ;-)
>> >
>> > - ForkingVMTestRunner
>> > a runner executing the unit tests in a forked virtual machine allowing to test effect of command line JVM switches for instance
>> >
>> > - ParrallelRunner
>> > JUnit already contains nearly the whole code for that but not available as runner running tests in parallel
>> >
>> > - ParameterizedRunner
>> > a runner far more flexible than JUnit's Parameterized runner allowing to configure usage per method (a bit like TestNG) and for different types
>> >
>> > - @NotYetImplemented
>> > this is an annotation allowing to indicate that a unit test is expected to fail. A failure should be reported as success whereas a success should be reported as failure. This has proven to be far more interesting than @Ignore which is just a little better than removing a test: @NotYetImplemented allows to write tests for "accepted" bugs or future features and to get notified when they are fixed as side effect of other changes
>> >
>> > - assertEquals & IDE integration
>> > small improvement to throw ComparisonFailure not only for String comparison what allows IDE like Eclipse to better display differences between expected and actual result.
>> >
>> > Cheers,
>> > Marc.
>> >
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
> <*> To visit your group on the web, go to:
>    http://groups.yahoo.com/group/junit/
>
> <*> Your email settings:
>    Individual Email | Traditional
>
> <*> To change settings online go to:
>    http://groups.yahoo.com/group/junit/join
>    (Yahoo! ID required)
>
> <*> To change settings via email:
>    jun...@ya...
>    jun...@ya...
>
> <*> To unsubscribe from this group, send an email to:
>    jun...@ya...
>
> <*> Your use of Yahoo! Groups is subject to:
>    http://docs.yahoo.com/info/terms/
>
>

Re: [Junit-devel] Title: JUnit 4.9b2 (beta-)released

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

[everyone, be sure to reply-all to be sure the list is included (the
sourceforge lists seem to have less reliable Reply-To fields.)]



On Thu, Feb 3, 2011 at 4:32 PM, dgageot <dg...@gm...> wrote:
> Hi, everyone. Thank you for the good work.
>
> I was wondering, what made you choose TestRule to be an abstract class and not an interface? This is so much of a pain.

In your position, I'd also be frustrated.

> The class being empty, I don't get it.

The idea was to guide people away from an improper usage of Rules.
For example, calling Timeout.apply in the middle of a test method is
so likely to be the wrong thing to do, that we wanted to make it
difficult.  If there were some way for a rule to expose one interface
to the framework, and another to test writers, that would be ideal.
This seemed like the next-best solution.

> One of my custom Rules needs to extend a class already.

Can you go into more details about this case, and how hard it would be
to adapt your code to use TestRule?

> If I leave it implementing the deprecated MethodRule, everything is ok as long as I don't add another rule to the test.
> If a rule based on TestRule is used, any rule based on MethodRule seems to be silently ignored.

This isn't what should be happening.  The ordering of multiple rules
is undefined.  What this means is that if you have a Rule (whether
TestRule or MethodRule) that sometimes or always blocks or interrupts
the call to base.evaluate(), then it may prevent other rules from
starting or completing.

There's been recent discussion on a way to be explicit about the
ordering of rule application.  If that would be helpful here, let me
know.

So, I now have 1 user (kcooney) on record for preferring the abstract
superclass (because it prevents confusion and improper usage), and one
(dgageot) on record preferring the interface (because it frees up the
superclass slot).  If anyone else has opinions, please chime in by
this time Monday, so we can make a decision and lock it in.  Thanks,

   David Saff

>
> David.
> @dgageot
>
>
> --- In ju...@ya..., David Saff <david@...> wrote:
>>
>> Hello, everyone.  We're happy to announce the release of JUnit 4.9b2.
>> This release's theme is Test-class and suite level Rules.
>> More information linked from
>> http://saffgreenbar.blogspot.com/2011/01/junit-49b2-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();
>>
>>               @Rule
>>               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.
>>
>> `TestRule` is an abstract base class, and its abstract `apply` method is
>> protected.  In order to apply `TestRule`s to a `Statement`, use the `RunRules`
>> class in `org.junit.rules` (thanks to `@kcooney`)
>>
>> ### 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#163: Bad comparison failure message when using
>> assertEquals(String, String)
>>
>>   Thanks to `@kcooney`
>>
>> ### Minor changes ###
>>
>> - Backed out unused folder "experimental-use-of-antunit", replaced by
>>   bash-based script at build_tests.sh
>>
>> - Made MultipleFailureException public, to assist extension writers.
>>   Thanks to `@kcooney`
>>
>
>
>

Re: [Junit-devel] to run single test in junit 4 from a main method

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

(Oops, I dropped the list on the first reply.  Re-adding)

Inba,

For more sophisticated rules about what to include, and what to exclude, see

Request.aClass(SomeClass.class).filterWith(myFilter)

Check out the docs on Filter and filterWith to move forward from
there.  Good luck,

   David

On Tue, Feb 1, 2011 at 3:35 PM, Inbaselvan Gandhi <inb...@gm...> wrote:
> Thanks David,  i still getting used to Junit. I just tried and it worked.
> What i couldn't search was for an option to pass a list of methods that i
> would like to execute. Say in this case A and C  just not B. I couldn't even
> spot the right docs, if you can help me in this it would be great.
>
> Regards,
> Inba
>
>
> On Tue, Feb 1, 2011 at 2:27 PM, David Saff <da...@sa...> wrote:
>>
>> Because you're running a method in a JUnit-4-style test class, you'll
>> need to use the JUnit 4 test-running mechanism, which is in the
>> org.junit package.  Something like:
>>
>> JUnitCore core = new JUnitCore();
>> core.addListener(new TextListener(new RealSystem()));
>> core.run(Request.method(myClass, "methodName"))
>>
>> Share and enjoy,
>>
>>   David
>>
>> On Tue, Feb 1, 2011 at 11:31 AM, inba <inb...@gm...> wrote:
>> >
>> > public class TESTCLASS  {
>> >
>> >        @Before
>> >        public void setUp(){
>> >                //some setup
>> >        }
>> >
>> >        @Test
>> >        public void testA() {
>> >                //some test
>> >        }
>> >
>> >        @Test
>> >        public void testB(){
>> >                //some test
>> >        }
>> >
>> >        @Test
>> >        public void testB(){
>> >                //some test
>> >        }
>> > }
>> >
>> > To run a single method testB in the above class I have code in a main()
>> > as
>> > below
>> >
>> > new TestRunner().start(new
>> > String[]{"-c","TESTCLASS","-m","TESTCLASS.testB"});
>> >
>> >
>> > but this doesn't work and i get an error like this
>> >
>> > Exception in thread "main" java.lang.Exception: Could not create and run
>> > test suite: java.lang.ClassCastException: class TESTCLASS at
>> > junit.textui.TestRunner.start(TestRunner.java:182)
>> >
>> >
>> >
>> > I am trying to execute a method selected in a swing application. At the
>> > end
>> > i would want to get a list of selected methods in the swing gui to be
>> > executed. how do i do this ?
>> >
>> >
>> > --
>> > View this message in context:
>> > http://old.nabble.com/to-run-single-test-in-junit-4-from-a-main-method-tp30814050p30814050.html
>> > Sent from the JUnit - Dev mailing list archive at Nabble.com.
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>> > Finally, a world-class log management solution at an even better
>> > price-free!
>> > Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> > February 28th, so secure your free ArcSight Logger TODAY!
>> > http://p.sf.net/sfu/arcsight-sfd2d
>> > _______________________________________________
>> > Junit-devel mailing list
>> > Jun...@li...
>> > https://lists.sourceforge.net/lists/listinfo/junit-devel
>> >
>
>

[Junit-devel] to run single test in junit 4 from a main method

[inba <inb...@gm...>]

public class TESTCLASS  {	
	
	@Before
	public void setUp(){
		//some setup
	}
	
	@Test
	public void testA() {
		//some test
	}
	
	@Test
	public void testB(){
		//some test
	}

        @Test
	public void testB(){
		//some test
	}
}

To run a single method testB in the above class I have code in a main() as
below 

new TestRunner().start(new
String[]{"-c","TESTCLASS","-m","TESTCLASS.testB"}); 


but this doesn't work and i get an error like this 

Exception in thread "main" java.lang.Exception: Could not create and run
test suite: java.lang.ClassCastException: class TESTCLASS at
junit.textui.TestRunner.start(TestRunner.java:182) 



I am trying to execute a method selected in a swing application. At the end
i would want to get a list of selected methods in the swing gui to be
executed. how do i do this ?


-- 
View this message in context: http://old.nabble.com/to-run-single-test-in-junit-4-from-a-main-method-tp30814050p30814050.html
Sent from the JUnit - Dev mailing list archive at Nabble.com.

[Junit-devel] Title: JUnit 4.9b2 (beta-)released

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

Hello, everyone.  We're happy to announce the release of JUnit 4.9b2.
This release's theme is Test-class and suite level Rules.
More information linked from
http://saffgreenbar.blogspot.com/2011/01/junit-49b2-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();
	
		@Rule
		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.

`TestRule` is an abstract base class, and its abstract `apply` method is
protected.  In order to apply `TestRule`s to a `Statement`, use the `RunRules`
class in `org.junit.rules` (thanks to `@kcooney`)

### 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#163: Bad comparison failure message when using
assertEquals(String, String)

  Thanks to `@kcooney`

### Minor changes ###

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

- Made MultipleFailureException public, to assist extension writers.
  Thanks to `@kcooney`

[Junit-devel] Revisionist history...

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

Hi, all.

Recently, I've begun playing with a homebrew build system that enables
local rollbacks by using a local git history.  Sometime in the last
two weeks, I accidentally pushed some of that local history to
github.com/dsaff/junit and github.com/KentBeck/junit.  I decided to
retroactively delete these spurious commits.  If you've pulled from
HEAD of either of those repos in the last few weeks, you may need to
re-pull or rebase.  I'm happy to help if this causes difficulties for
anyone.

My apologies,

   David Saff

[Junit-devel] Soumya S Pattnayak is OOO.

[Soumya S P. <spa...@in...>]

I will be out of the office starting  08/30/2010 and will not return until
09/03/2010.

I will be out of the office starting 30/08/2010 and will not return until
03/09/2010.

[Junit-devel] Blocker: Exceptions hidden in DataPoint creation

[Johannes S. <mai...@ce...>]

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

This issues drives me crazy:
http://github.com/KentBeck/junit/issues/issue/137

I think this is one of those things that really should be fixed. Unit
Testing must be reliable...

Any chance to see this fixed?


Thanks,

Johannes

- -- 
Johannes Schneider - blog.cedarsoft.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJMfMKOAAoJEAytD9R7Qv6dKhYH/jUGYk+aRctDJkbJU+kZkUbI
YIVXAP+OJDVKPhUJX/fqi99NvMw/w4zWzbF8JEke7pcGDEwoocTCgCxZf6ferHBb
+GHFo/RaYDf2zmJeWoi2FiaZeeezFdcgcSeDkLUqdjhYp9iLh8LyBcucUFOLBL1+
Y5ysxofY0lOI77zsBG1iHs5Sc+94zLWJonTPn/yB0M8EnTvAOIoBZ1Acze4lGTVp
l57G+Kq/52TozRWXLS3RCn1aQxX3+asLu/+JGruOJtLBju/69QR5yPbqtnD9O4pI
167N63wpPQ1Styz/6pq5BaQDNKTm1dTG8CHqvAcOY8ekxZq/MavcfjYmualIVe0=
=ZfEN
-----END PGP SIGNATURE-----

Re: [Junit-devel] Bug(?) in Theories with non-static @DataPoint method

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

On Wed, Jul 28, 2010 at 10:13 AM, Johannes Schneider
<mai...@ce...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/23/2010 09:53 PM, David Saff wrote:
>> Johannes,
>>
>> Sorry to be so long in getting back to you.
>
> No problem. But can you tell me where the devs are discussing?

The junit-devel list (cc'ed) is the best location for e-mail
discussion.  Most discussion between Kent and I is by voice, however.

> I have some ideas I'd like to share with them.
>
>> Have you opened a bug on github?
>
> will do that.
>
>
> Johannes
>
>>
>>    David Saff
>>
>> On Sat, Jul 10, 2010 at 7:31 AM, Johannes Schneider
>> <mai...@ce...> wrote:
>> Hi guys,
>>
>> don't know where to post, so hopefully this list is the right one.
>>
>> I run into some problems related to Theories and DataPoints (with 4.8.1):
>>
>>
>> This test is marked as successfull but did *not* run:
>>
>> @RunWith( Theories.class )
>> public class TheoriesTest {
>>  @Theory
>>  public void aTheory( String arg ) {
>>    System.out.println( "TheoriesTest.aTheory(" + arg + ")" );
>>    assertNotNull( arg );
>>  }
>>
>>  @DataPoint
>>  public String getParam() {
>>    return "daParam";
>>  }
>> }
>>
>>
>> I think the problem lies in Theories:126.
>> statement.evaluate() catches exceptions silently
>> (org.junit.experimental.theories.Theories.TheoryAnchor#methodCompletesWithParameters:158).
>>
>> Therefore "handleDataPointSuccess" is called even when an exception has
>> been thrown....
>>
>>
>>
>> So I think there are at least two things missing:
>> - Proper exception handling...
>> - Checking the DataPoint(s) methods for the static keyword
>>
>>
>> By the way: Why isn't it allowed to return Iterables or at least Lists
>> in @DataPoints methods?
>>
>>
>>
>> Thanks,
>>
>> Johannes
>>
>>>
> -
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>>>
>
> - --
> Johannes Schneider - blog.cedarsoft.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEcBAEBAgAGBQJMUDsgAAoJEAytD9R7Qv6dZH8IAIgyiRFm6Hx5AjTGuQWsv7xO
> H3j3OJiHRXrb610pDlUpVj8iwlRspB0sR0PUEalxWeePpEZ7JPva/1j2JH8jnNHX
> +1VMNqsWFxCRvistvQvV/jLTKmWFSxOTXdgP4Q1lm6baXQPP6Dr342bEuDpWYnZp
> VacxMVRqScrCxyVt5yOSW0rkKxGmHOxjRrC8QeYAQJlVO+3BzmbbqqsL1C4QCCX9
> TROc9Ga1zAJlpSThqJd1PBBMVcDGTsNVECebrC9bGTWLzYRLxC6N9BkoFUaxkceG
> Q7G7h/cvn+QlV3VbmiY7hMGNul3oc3wjZ35e/TXDZcaA5+15HdKpby4zRkjFzME=
> =8I6j
> -----END PGP SIGNATURE-----
>

Re: [Junit-devel] Bug(?) in Theories with non-static @DataPoint method

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

Johannes,

Sorry to be so long in getting back to you.  Have you opened a bug on github?

   David Saff

On Sat, Jul 10, 2010 at 7:31 AM, Johannes Schneider
<mai...@ce...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi guys,
>
> don't know where to post, so hopefully this list is the right one.
>
> I run into some problems related to Theories and DataPoints (with 4.8.1):
>
>
> This test is marked as successfull but did *not* run:
>
> @RunWith( Theories.class )
> public class TheoriesTest {
>  @Theory
>  public void aTheory( String arg ) {
>    System.out.println( "TheoriesTest.aTheory(" + arg + ")" );
>    assertNotNull( arg );
>  }
>
>  @DataPoint
>  public String getParam() {
>    return "daParam";
>  }
> }
>
>
> I think the problem lies in Theories:126.
> statement.evaluate() catches exceptions silently
> (org.junit.experimental.theories.Theories.TheoryAnchor#methodCompletesWithParameters:158).
>
> Therefore "handleDataPointSuccess" is called even when an exception has
> been thrown....
>
>
>
> So I think there are at least two things missing:
> - - Proper exception handling...
> - - Checking the DataPoint(s) methods for the static keyword
>
>
> By the way: Why isn't it allowed to return Iterables or at least Lists
> in @DataPoints methods?
>
>
>
> Thanks,
>
> Johannes
>
> - --
> Johannes Schneider - blog.cedarsoft.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEcBAEBAgAGBQJMOFomAAoJEAytD9R7Qv6dOjoH/2Lde0wr10KtWyUDK2Xf+fB+
> Fy8tBXmNvQiJAjdeA0zI+yt1SPg0dcWkrDOqLvP+3BBh+3uis1J4ZW0/1zU8zQhX
> 1tzeZ0S+gYopRnxxgc5Zmpc1ErD5kwNykwz0JbjGxFe6VccOvnjQp6BYRyoaKHOh
> tXzoGKFCSjKU8N+xSzLouoVQmjfp4KsOTHYRpHeiPcvf9X33WlJ8/fIAlxYW6mvu
> Fg8AoQ93BEQk4Qp6S1PeupRuconKOIViM8+E2a2lz9C8MKqo8WL9V+23J5fe7qvi
> Y2OktebVLu54Vz48sfdhfDz+YhXRJegxDfbmXNx8+Sbn44yvLIpbk2mKW68aWrw=
> =zW6R
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>

[Junit-devel] Bug(?) in Theories with non-static @DataPoint method

[Johannes S. <mai...@ce...>]

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

Hi guys,

don't know where to post, so hopefully this list is the right one.

I run into some problems related to Theories and DataPoints (with 4.8.1):


This test is marked as successfull but did *not* run:

@RunWith( Theories.class )
public class TheoriesTest {
  @Theory
  public void aTheory( String arg ) {
    System.out.println( "TheoriesTest.aTheory(" + arg + ")" );
    assertNotNull( arg );
  }

  @DataPoint
  public String getParam() {
    return "daParam";
  }
}


I think the problem lies in Theories:126.
statement.evaluate() catches exceptions silently
(org.junit.experimental.theories.Theories.TheoryAnchor#methodCompletesWithParameters:158).

Therefore "handleDataPointSuccess" is called even when an exception has
been thrown....



So I think there are at least two things missing:
- - Proper exception handling...
- - Checking the DataPoint(s) methods for the static keyword


By the way: Why isn't it allowed to return Iterables or at least Lists
in @DataPoints methods?



Thanks,

Johannes

- -- 
Johannes Schneider - blog.cedarsoft.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJMOFomAAoJEAytD9R7Qv6dOjoH/2Lde0wr10KtWyUDK2Xf+fB+
Fy8tBXmNvQiJAjdeA0zI+yt1SPg0dcWkrDOqLvP+3BBh+3uis1J4ZW0/1zU8zQhX
1tzeZ0S+gYopRnxxgc5Zmpc1ErD5kwNykwz0JbjGxFe6VccOvnjQp6BYRyoaKHOh
tXzoGKFCSjKU8N+xSzLouoVQmjfp4KsOTHYRpHeiPcvf9X33WlJ8/fIAlxYW6mvu
Fg8AoQ93BEQk4Qp6S1PeupRuconKOIViM8+E2a2lz9C8MKqo8WL9V+23J5fe7qvi
Y2OktebVLu54Vz48sfdhfDz+YhXRJegxDfbmXNx8+Sbn44yvLIpbk2mKW68aWrw=
=zW6R
-----END PGP SIGNATURE-----

Re: [Junit-devel] Synching junit-dep to Maven Central repo

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

Mauro,

I've been very delinquent in getting us hooked up into Maven.  It's
not done yet.

   David

On Sun, Jun 13, 2010 at 5:16 AM, Mauro Talevi
<mau...@aq...> wrote:
> Hi David,
>
> I see the download page (http://github.com/KentBeck/junit/downloads)
> getting updates but the artifact don't seem to be synched with the
> central maven repo.   Are they uploaded to any other repo?
>
> Thanks,
> Mauro
>
> On 05/04/2010 14:57, David Saff wrote:
>> [+junit-devel]
>>
>> Mauro,
>>
>> Neither Kent nor I have ever released anything to maven--anything you
>> find there was uploaded by someone else.  We plan to change this with
>> the next release, and explicitly upload to maven, by very popular
>> request.  Please keep us honest if we don't upload both.  Thanks,
>>
>>    David Saff
>>
>> On Mon, Apr 5, 2010 at 7:55 AM, Mauro Talevi <mau...@aq...> wrote:
>>
>>> Hi David,
>>>
>>> I've noticed that while the junit-dep.jar artifact is being regularly
>>> released alongside junit.jar, only the junit.jar is being synched to the
>>> Maven Central repo.  junit-dep artifacts stopped being synched after 4.5:
>>>
>>> http://repo1.maven.org/maven2/junit/junit/
>>> http://repo1.maven.org/maven2/junit/junit-dep/
>>>
>>> I've was just wondering if there was a reason for this or simply an
>>> oversight.
>>>
>>> I'm not sure how the synching/upload of junit.jar is done, but could the
>>> synch also include junit-dep?
>>>
>>> I would greatly appreciate it.
>>>
>>> Thanks and regards,
>>> Mauro
>>>
>>>
>>>
>
>

[Junit-devel] JUnit 4.8.2 is released

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

This is a small bugfix release:

http://kentbeck.github.com/junit/doc/ReleaseNotes4.8.2.html

Download from http://github.com/KentBeck/junit/downloads

   David Saff