4.5 release candidate

[kentb]

All,

Following our discussions last week, we have incorporated the old
JUnit4ClassRunner into 4.5. (The new runner is called BlockJUnit4ClassRunner
because it is organized as a "block" of "statements" instead of nested
procedures). Those of you who have written custom runners, we'd appreciate
it if you could try out the release candidate to make sure it supports your
existing runners.

Next up, release notes and then out the door!

Whew!

Kent Beck
Three Rivers Institute

[Johannes Link-2]

Hi Kent,

Maybe you could provide it as jar file on
http://sourceforge.net/projects/junit/ ?
There are already other 4.5 snapshots out there and it would relieve
me and other runner providers from going through the svn checkout &
package hassle.

Thanks,
Johannes

--- In junit@..., "Kent Beck" <kentb@...> wrote:
>
> All,
>
> Following our discussions last week, we have incorporated the old
> JUnit4ClassRunner into 4.5. (The new runner is called
BlockJUnit4ClassRunner
> because it is organized as a "block" of "statements" instead of nested
> procedures). Those of you who have written custom runners, we'd
appreciate
> it if you could try out the release candidate to make sure it
supports your
> existing runners.
>
> Next up, release notes and then out the door!
>
> Whew!
>
> Kent Beck
> Three Rivers Institute
>

[kentb]

Done.
 
Kent Beck
Three Rivers Institute

  _____  

From: junit@... [mailto:junit@...] On Behalf Of
Johannes Link
Sent: Tuesday, June 17, 2008 1:30 AM
To: junit@...
Subject: [junit] Re: 4.5 release candidate



Hi Kent,

Maybe you could provide it as jar file on
http://sourceforge. <http://sourceforge.net/projects/junit/>
net/projects/junit/ ?
There are already other 4.5 snapshots out there and it would relieve
me and other runner providers from going through the svn checkout &
package hassle.

Thanks,
Johannes

--- In junit@yahoogroups. <mailto:junit%40yahoogroups.com> com, "Kent Beck"
<kentb@...> wrote:
>
> All,
>
> Following our discussions last week, we have incorporated the old
> JUnit4ClassRunner into 4.5. (The new runner is called
BlockJUnit4ClassRunner
> because it is organized as a "block" of "statements" instead of nested
> procedures). Those of you who have written custom runners, we'd
appreciate
> it if you could try out the release candidate to make sure it
supports your
> existing runners.
>
> Next up, release notes and then out the door!
>
> Whew!
>
> Kent Beck
> Three Rivers Institute
>



 


[Non-text portions of this message have been removed]

[Pascale, Peter H.]

Are there any previews as to new features in junit 4.5? I understand
that's partly what Kent is referring to in his note:

 

"Next up, release notes and then out the door!"

 

Anything informal at this stage? Is it just around the corner such that
I should sit tight?

 

 

Here's the case we're interested in. We would like introduce a
functional-test build on our integration server. Something we could run
on a regular basis, but not as part of the integration build. The
current thinking call for introduction of a custom Runner that
identifies functional test based on a custom annotation. Then we can
co-mingle unit and functional tests, not relying on directory
segregation. Does 4.5 have any useful features for this problem? At a
minimum I've picked up that writing a custom Runner will be easier...

 

Thanks!

 

Peter Pascale



 

All,

Following our discussions last week, we have incorporated the old
JUnit4ClassRunner into 4.5. (The new runner is called
BlockJUnit4ClassRunner
because it is organized as a "block" of "statements" instead of nested
procedures). Those of you who have written custom runners, we'd
appreciate
it if you could try out the release candidate to make sure it supports
your
existing runners.

Next up, release notes and then out the door!

Whew!

Kent Beck
Three Rivers Institute


****************************************************************************
This email may contain material confidential to
Pearson.  If you were not an intended recipient,
please notify the sender and delete all copies.
We may monitor email to and from our network.
****************************************************************************


[Non-text portions of this message have been removed]

[Johannes Link-2]

The constructor:
    protected Suite(Class<?> klass, Class<?>[] annotatedClasses)
        throws InitializationError {...}
seems to be missing from the Suite class.

This breaks my code in ClasspathSuite:
        /**
         * Internal use only.
         */
        public ClasspathSuite(Class<?> klass) throws
                        InitializationError {
                super(klass, getSortedTestclasses(klass));
        }

I'm sure this is easy to fix but it forces me to release a new version.

Johannes

--- In junit@..., "Kent Beck" <kentb@...> wrote:
>
> All,
>
> Following our discussions last week, we have incorporated the old
> JUnit4ClassRunner into 4.5. (The new runner is called
BlockJUnit4ClassRunner
> because it is organized as a "block" of "statements" instead of nested
> procedures). Those of you who have written custom runners, we'd
appreciate
> it if you could try out the release candidate to make sure it
supports your
> existing runners.
>
> Next up, release notes and then out the door!
>
> Whew!
>
> Kent Beck
> Three Rivers Institute
>

[Nat Pryce]

JUnit 4.5 breaks jMock 2 because the TestMethod class has been moved
to a different package.

It's our fault for subclassing JUnit4ClassRunner, but it would be nice
if JUnit4ClassRunner did not change at all in this release.

--Nat

2008/6/16 Kent Beck <kentb@...>:

> All,
>
> Following our discussions last week, we have incorporated the old
> JUnit4ClassRunner into 4.5. (The new runner is called BlockJUnit4ClassRunner
> because it is organized as a "block" of "statements" instead of nested
> procedures). Those of you who have written custom runners, we'd appreciate
> it if you could try out the release candidate to make sure it supports your
> existing runners.
>
> Next up, release notes and then out the door!
>
> Whew!
>
> Kent Beck
> Three Rivers Institute
>
>

[Nat Pryce]

I've ported the jMock runner over to the new structure.  Here are some
comments on the experience.

I extended BlockJUnit4ClassRunner and override the invoke(...) method
to verify the mock objects after the test has run, but before tear-down.

This way reduces the amount of code in the custom runner.  I also
didn't have to duplicate existing functionality because the invoke
method let me hook in at the right point.

However, I still had to use classes in the org.junit.internal package,
which feels wrong.  Have I missed the right way of doing this?

Other niggles...

- The classes are compiled for Java 6 only, but only seem to need
language features from 5 and above.  Can the release be compiled for
Java 5?

- The JUnit 4.4 classes have been deprecated *and* moved to another
package, which breaks any code that used them.  There's no point in
doing both.  Either break backward compatability or keep backward
compatability and deprecate the classes.  I'd prefer the latter, since
it will allow me to do a jMock with new features supporting both JUnit
4.4 and 4.5 and then release a version that brings support forward to
4.5 onwards.

Cheers,
    --Nat.

--- In junit@..., "Nat Pryce" <nat.pryce@...> wrote:

>
> JUnit 4.5 breaks jMock 2 because the TestMethod class has been moved
> to a different package.
>
> It's our fault for subclassing JUnit4ClassRunner, but it would be nice
> if JUnit4ClassRunner did not change at all in this release.
>
> --Nat
>
> 2008/6/16 Kent Beck <kentb@...>:
> > All,
> >
> > Following our discussions last week, we have incorporated the old
> > JUnit4ClassRunner into 4.5. (The new runner is called

BlockJUnit4ClassRunner
> > because it is organized as a "block" of "statements" instead of nested
> > procedures). Those of you who have written custom runners, we'd
appreciate
> > it if you could try out the release candidate to make sure it
supports your

> > existing runners.
> >
> > Next up, release notes and then out the door!
> >
> > Whew!
> >
> > Kent Beck
> > Three Rivers Institute
> >
> >
>

[kentb]

Nat,
 
I'm glad the new format worked better for you. BlockJUnit4TestRunner and its
supporting cast are intended to be published in the next release. However,
they are new enough that we wanted to verify their efficacy and give
ourselves a chance to refine them before many people used them.
 
Point well taken on the redundancy of deprecation and moving the classes.
We'll move them back before releasing. We will compile the final release
with Java 5 as well.
 
Thank you very much for the feedback.
 
Regards,
 
Kent Beck
Three Rivers Institute

  _____  

From: junit@... [mailto:junit@...] On Behalf Of
nat_pryce
Sent: Thursday, June 19, 2008 3:16 AM
To: junit@...
Subject: [junit] Re: 4.5 release candidate



I've ported the jMock runner over to the new structure. Here are some
comments on the experience.

I extended BlockJUnit4ClassRunner and override the invoke(...) method
to verify the mock objects after the test has run, but before tear-down.

This way reduces the amount of code in the custom runner. I also
didn't have to duplicate existing functionality because the invoke
method let me hook in at the right point.

However, I still had to use classes in the org.junit.internal package,
which feels wrong. Have I missed the right way of doing this?

Other niggles...

- The classes are compiled for Java 6 only, but only seem to need
language features from 5 and above. Can the release be compiled for
Java 5?

- The JUnit 4.4 classes have been deprecated *and* moved to another
package, which breaks any code that used them. There's no point in
doing both. Either break backward compatability or keep backward
compatability and deprecate the classes. I'd prefer the latter, since
it will allow me to do a jMock with new features supporting both JUnit
4.4 and 4.5 and then release a version that brings support forward to
4.5 onwards.

Cheers,
--Nat.

--- In junit@yahoogroups. <mailto:junit%40yahoogroups.com> com, "Nat Pryce"
<nat.pryce@...> wrote:

>
> JUnit 4.5 breaks jMock 2 because the TestMethod class has been moved
> to a different package.
>
> It's our fault for subclassing JUnit4ClassRunner, but it would be nice
> if JUnit4ClassRunner did not change at all in this release.
>
> --Nat
>
> 2008/6/16 Kent Beck <kentb@...>:
> > All,
> >
> > Following our discussions last week, we have incorporated the old
> > JUnit4ClassRunner into 4.5. (The new runner is called

BlockJUnit4ClassRunner
> > because it is organized as a "block" of "statements" instead of nested
> > procedures). Those of you who have written custom runners, we'd
appreciate
> > it if you could try out the release candidate to make sure it
supports your

> > existing runners.
> >
> > Next up, release notes and then out the door!
> >
> > Whew!
> >
> > Kent Beck
> > Three Rivers Institute
> >
> >
>

 


[Non-text portions of this message have been removed]

[kentb]

Johannes,
 
Thank you for the report. I suspect we took out that constructor because we
didn't find any uses of it. Unfortunately, alt-shft-g in Eclipse only
searches my code, not everyones :-) (hmmm... any eager graduate students out
there?). We will restore the missing constructor or explain the reason why
we can't before the release.
 
Best regards,
 
Kent Beck
Three Rivers Institute

  _____  

From: junit@... [mailto:junit@...] On Behalf Of
Johannes Link
Sent: Wednesday, June 18, 2008 2:54 AM
To: junit@...
Subject: [junit] Re: 4.5 release candidate



The constructor:
protected Suite(Class<?> klass, Class<?>[] annotatedClasses)
throws InitializationError {...}
seems to be missing from the Suite class.

This breaks my code in ClasspathSuite:
/**
* Internal use only.
*/
public ClasspathSuite(Class<?> klass) throws
InitializationError {
super(klass, getSortedTestclasses(klass));
}

I'm sure this is easy to fix but it forces me to release a new version.

Johannes

--- In junit@yahoogroups. <mailto:junit%40yahoogroups.com> com, "Kent Beck"
<kentb@...> wrote:
>
> All,
>
> Following our discussions last week, we have incorporated the old
> JUnit4ClassRunner into 4.5. (The new runner is called
BlockJUnit4ClassRunner
> because it is organized as a "block" of "statements" instead of nested
> procedures). Those of you who have written custom runners, we'd
appreciate
> it if you could try out the release candidate to make sure it
supports your
> existing runners.
>
> Next up, release notes and then out the door!
>
> Whew!
>
> Kent Beck
> Three Rivers Institute
>



 


[Non-text portions of this message have been removed]

[kentb]

Dear Peter,
 
The major change is the reorganization of JUnit4TestRunner into
BlockJUnit4TestRunner. This is in an internal package, so most users won't
see the difference. I can't think of major functional changes. I'll go
through all the diffs before I would swear to it, though.
 
Regards,
 
Kent Beck
Three Rivers Institute

  _____  

From: junit@... [mailto:junit@...] On Behalf Of
Pascale, Peter H.
Sent: Tuesday, June 17, 2008 1:51 PM
To: junit@...
Cc: Goeden, Chris J
Subject: [junit] RE: 4.5 Release Candidate



Are there any previews as to new features in junit 4.5? I understand
that's partly what Kent is referring to in his note:

"Next up, release notes and then out the door!"

Anything informal at this stage? Is it just around the corner such that
I should sit tight?

Here's the case we're interested in. We would like introduce a
functional-test build on our integration server. Something we could run
on a regular basis, but not as part of the integration build. The
current thinking call for introduction of a custom Runner that
identifies functional test based on a custom annotation. Then we can
co-mingle unit and functional tests, not relying on directory
segregation. Does 4.5 have any useful features for this problem? At a
minimum I've picked up that writing a custom Runner will be easier...

Thanks!

Peter Pascale

All,

Following our discussions last week, we have incorporated the old
JUnit4ClassRunner into 4.5. (The new runner is called
BlockJUnit4ClassRunner
because it is organized as a "block" of "statements" instead of nested
procedures). Those of you who have written custom runners, we'd
appreciate
it if you could try out the release candidate to make sure it supports
your
existing runners.

Next up, release notes and then out the door!

Whew!

Kent Beck
Three Rivers Institute

****************************************************************************

This email may contain material confidential to
Pearson. If you were not an intended recipient,
please notify the sender and delete all copies.
We may monitor email to and from our network.
****************************************************************************

[Non-text portions of this message have been removed]



 


[Non-text portions of this message have been removed]

[Nat Pryce]

One other uncertainty I had with the new API.  BlockJUnit4TestRunner
has two constructors, one which takes a TestClass and one which takes
a Class delegates to the former.  

Why two?

Which should I override for my subclass?  That is, which does the
framework use to create a test-runner?

--Nat

--- In junit@..., "Kent Beck" <kentb@...> wrote:
>
> Nat,
>  
> I'm glad the new format worked better for you. BlockJUnit4TestRunner
and its
> supporting cast are intended to be published in the next release.
However,
> they are new enough that we wanted to verify their efficacy and give
> ourselves a chance to refine them before many people used them.
>  
> Point well taken on the redundancy of deprecation and moving the
classes.

> We'll move them back before releasing. We will compile the final release
> with Java 5 as well.
>  
> Thank you very much for the feedback.
>  
> Regards,
>  
> Kent Beck
> Three Rivers Institute
>
>   _____  
>
> From: junit@... [mailto:junit@...] On Behalf Of
> nat_pryce
> Sent: Thursday, June 19, 2008 3:16 AM
> To: junit@...
> Subject: [junit] Re: 4.5 release candidate
>
>
>
> I've ported the jMock runner over to the new structure. Here are some
> comments on the experience.
>
> I extended BlockJUnit4ClassRunner and override the invoke(...) method
> to verify the mock objects after the test has run, but before tear-down.
>
> This way reduces the amount of code in the custom runner. I also
> didn't have to duplicate existing functionality because the invoke
> method let me hook in at the right point.
>
> However, I still had to use classes in the org.junit.internal package,
> which feels wrong. Have I missed the right way of doing this?
>
> Other niggles...
>
> - The classes are compiled for Java 6 only, but only seem to need
> language features from 5 and above. Can the release be compiled for
> Java 5?
>
> - The JUnit 4.4 classes have been deprecated *and* moved to another
> package, which breaks any code that used them. There's no point in
> doing both. Either break backward compatability or keep backward
> compatability and deprecate the classes. I'd prefer the latter, since
> it will allow me to do a jMock with new features supporting both JUnit
> 4.4 and 4.5 and then release a version that brings support forward to
> 4.5 onwards.
>
> Cheers,
> --Nat.
>
> --- In junit@yahoogroups. <mailto:junit%40yahoogroups.com> com, "Nat

Pryce"

> <nat.pryce@> wrote:
> >
> > JUnit 4.5 breaks jMock 2 because the TestMethod class has been moved
> > to a different package.
> >
> > It's our fault for subclassing JUnit4ClassRunner, but it would be nice
> > if JUnit4ClassRunner did not change at all in this release.
> >
> > --Nat
> >
> > 2008/6/16 Kent Beck <kentb@>:
> > > All,
> > >
> > > Following our discussions last week, we have incorporated the old
> > > JUnit4ClassRunner into 4.5. (The new runner is called
> BlockJUnit4ClassRunner
> > > because it is organized as a "block" of "statements" instead of

nested

> > > procedures). Those of you who have written custom runners, we'd
> appreciate
> > > it if you could try out the release candidate to make sure it
> supports your
> > > existing runners.
> > >
> > > Next up, release notes and then out the door!
> > >
> > > Whew!
> > >
> > > Kent Beck
> > > Three Rivers Institute
> > >
> > >
> >
>
>
>
>  
>
>
> [Non-text portions of this message have been removed]
>

[Nat Pryce]

I've found a serious limitation with the new API: there's no easy way
to insert a statement into the chain of decorators so that it gets
access to the test object.

I originally inserted jMock's verification step after the test method
was invoked, by overriding invoke(...) and wrapping my own Statement
around that returned by super.invoke(...).  That was easy because
invoke is passed the test object.

However, it doesn't work: if the test throws an expected exception,
the verification is not performed.

Therefore, I need to insert jMock's verification after the check for
an expected exception.  But the possiblyExpectingExceptions method is
not passed the test object.  It is therefore impossible to implement
what I want without duplicating the implementation of
BlockJUnit4ClassRunner.childBlock, which is quite a big method and
doesn't seem to be a clean extension point.

One possible fix is, I think, for every factory method that creates a
Statement to have the same parameters: the test object, the test
method and, if applicable, the next link in the chain of Statements.

--Nat

2008/6/19 nat_pryce <nat.pryce@...>:

> One other uncertainty I had with the new API. BlockJUnit4TestRunner
> has two constructors, one which takes a TestClass and one which takes
> a Class delegates to the former.
>
> Why two?
>
> Which should I override for my subclass? That is, which does the
> framework use to create a test-runner?
>
> --Nat
>
> --- In junit@..., "Kent Beck" <kentb@...> wrote:
>>
>> Nat,
>>
>> I'm glad the new format worked better for you. BlockJUnit4TestRunner
> and its
>> supporting cast are intended to be published in the next release.
> However,
>> they are new enough that we wanted to verify their efficacy and give
>> ourselves a chance to refine them before many people used them.
>>
>> Point well taken on the redundancy of deprecation and moving the
> classes.
>> We'll move them back before releasing. We will compile the final release
>> with Java 5 as well.
>>
>> Thank you very much for the feedback.
>>
>> Regards,
>>
>> Kent Beck
>> Three Rivers Institute
>>
>> _____
>>
>> From: junit@... [mailto:junit@...] On Behalf Of
>> nat_pryce
>> Sent: Thursday, June 19, 2008 3:16 AM
>> To: junit@...
>> Subject: [junit] Re: 4.5 release candidate
>>
>>
>>
>> I've ported the jMock runner over to the new structure. Here are some
>> comments on the experience.
>>
>> I extended BlockJUnit4ClassRunner and override the invoke(...) method
>> to verify the mock objects after the test has run, but before tear-down.
>>
>> This way reduces the amount of code in the custom runner. I also
>> didn't have to duplicate existing functionality because the invoke
>> method let me hook in at the right point.
>>
>> However, I still had to use classes in the org.junit.internal package,
>> which feels wrong. Have I missed the right way of doing this?
>>
>> Other niggles...
>>
>> - The classes are compiled for Java 6 only, but only seem to need
>> language features from 5 and above. Can the release be compiled for
>> Java 5?
>>
>> - The JUnit 4.4 classes have been deprecated *and* moved to another
>> package, which breaks any code that used them. There's no point in
>> doing both. Either break backward compatability or keep backward
>> compatability and deprecate the classes. I'd prefer the latter, since
>> it will allow me to do a jMock with new features supporting both JUnit
>> 4.4 and 4.5 and then release a version that brings support forward to
>> 4.5 onwards.
>>
>> Cheers,
>> --Nat.
>>
>> --- In junit@yahoogroups. <mailto:junit%40yahoogroups.com> com, "Nat
> Pryce"
>> <nat.pryce@> wrote:
>> >
>> > JUnit 4.5 breaks jMock 2 because the TestMethod class has been moved
>> > to a different package.
>> >
>> > It's our fault for subclassing JUnit4ClassRunner, but it would be nice
>> > if JUnit4ClassRunner did not change at all in this release.
>> >
>> > --Nat
>> >
>> > 2008/6/16 Kent Beck <kentb@>:
>> > > All,
>> > >
>> > > Following our discussions last week, we have incorporated the old
>> > > JUnit4ClassRunner into 4.5. (The new runner is called
>> BlockJUnit4ClassRunner
>> > > because it is organized as a "block" of "statements" instead of
> nested
>> > > procedures). Those of you who have written custom runners, we'd
>> appreciate
>> > > it if you could try out the release candidate to make sure it
>> supports your
>> > > existing runners.
>> > >
>> > > Next up, release notes and then out the door!
>> > >
>> > > Whew!
>> > >
>> > > Kent Beck
>> > > Three Rivers Institute
>> > >
>> > >
>> >
>>
>>
>>
>>
>>
>>
>> [Non-text portions of this message have been removed]
>>
>
>

[David Saff]

Nat,

Good suggestion.  It's implemented in the new JUnit 4.5 beta 2, now
available for download.  Let me know if it makes things better.

   David Saff

On Sat, Jun 21, 2008 at 2:47 PM, Nat Pryce <nat.pryce@...> wrote:

> I've found a serious limitation with the new API: there's no easy way
> to insert a statement into the chain of decorators so that it gets
> access to the test object.
>
> I originally inserted jMock's verification step after the test method
> was invoked, by overriding invoke(...) and wrapping my own Statement
> around that returned by super.invoke(...).  That was easy because
> invoke is passed the test object.
>
> However, it doesn't work: if the test throws an expected exception,
> the verification is not performed.
>
> Therefore, I need to insert jMock's verification after the check for
> an expected exception.  But the possiblyExpectingExceptions method is
> not passed the test object.  It is therefore impossible to implement
> what I want without duplicating the implementation of
> BlockJUnit4ClassRunner.childBlock, which is quite a big method and
> doesn't seem to be a clean extension point.
>
> One possible fix is, I think, for every factory method that creates a
> Statement to have the same parameters: the test object, the test
> method and, if applicable, the next link in the chain of Statements.
>
> --Nat
>
> 2008/6/19 nat_pryce <nat.pryce@...>:
>> One other uncertainty I had with the new API. BlockJUnit4TestRunner
>> has two constructors, one which takes a TestClass and one which takes
>> a Class delegates to the former.
>>
>> Why two?
>>
>> Which should I override for my subclass? That is, which does the
>> framework use to create a test-runner?
>>
>> --Nat
>>
>> --- In junit@..., "Kent Beck" <kentb@...> wrote:
>>>
>>> Nat,
>>>
>>> I'm glad the new format worked better for you. BlockJUnit4TestRunner
>> and its
>>> supporting cast are intended to be published in the next release.
>> However,
>>> they are new enough that we wanted to verify their efficacy and give
>>> ourselves a chance to refine them before many people used them.
>>>
>>> Point well taken on the redundancy of deprecation and moving the
>> classes.
>>> We'll move them back before releasing. We will compile the final release
>>> with Java 5 as well.
>>>
>>> Thank you very much for the feedback.
>>>
>>> Regards,
>>>
>>> Kent Beck
>>> Three Rivers Institute
>>>
>>> _____
>>>
>>> From: junit@... [mailto:junit@...] On Behalf Of
>>> nat_pryce
>>> Sent: Thursday, June 19, 2008 3:16 AM
>>> To: junit@...
>>> Subject: [junit] Re: 4.5 release candidate
>>>
>>>
>>>
>>> I've ported the jMock runner over to the new structure. Here are some
>>> comments on the experience.
>>>
>>> I extended BlockJUnit4ClassRunner and override the invoke(...) method
>>> to verify the mock objects after the test has run, but before tear-down.
>>>
>>> This way reduces the amount of code in the custom runner. I also
>>> didn't have to duplicate existing functionality because the invoke
>>> method let me hook in at the right point.
>>>
>>> However, I still had to use classes in the org.junit.internal package,
>>> which feels wrong. Have I missed the right way of doing this?
>>>
>>> Other niggles...
>>>
>>> - The classes are compiled for Java 6 only, but only seem to need
>>> language features from 5 and above. Can the release be compiled for
>>> Java 5?
>>>
>>> - The JUnit 4.4 classes have been deprecated *and* moved to another
>>> package, which breaks any code that used them. There's no point in
>>> doing both. Either break backward compatability or keep backward
>>> compatability and deprecate the classes. I'd prefer the latter, since
>>> it will allow me to do a jMock with new features supporting both JUnit
>>> 4.4 and 4.5 and then release a version that brings support forward to
>>> 4.5 onwards.
>>>
>>> Cheers,
>>> --Nat.
>>>
>>> --- In junit@yahoogroups. <mailto:junit%40yahoogroups.com> com, "Nat
>> Pryce"
>>> <nat.pryce@> wrote:
>>> >
>>> > JUnit 4.5 breaks jMock 2 because the TestMethod class has been moved
>>> > to a different package.
>>> >
>>> > It's our fault for subclassing JUnit4ClassRunner, but it would be nice
>>> > if JUnit4ClassRunner did not change at all in this release.
>>> >
>>> > --Nat
>>> >
>>> > 2008/6/16 Kent Beck <kentb@>:
>>> > > All,
>>> > >
>>> > > Following our discussions last week, we have incorporated the old
>>> > > JUnit4ClassRunner into 4.5. (The new runner is called
>>> BlockJUnit4ClassRunner
>>> > > because it is organized as a "block" of "statements" instead of
>> nested
>>> > > procedures). Those of you who have written custom runners, we'd
>>> appreciate
>>> > > it if you could try out the release candidate to make sure it
>>> supports your
>>> > > existing runners.
>>> > >
>>> > > Next up, release notes and then out the door!
>>> > >
>>> > > Whew!
>>> > >
>>> > > Kent Beck
>>> > > Three Rivers Institute
>>> > >
>>> > >
>>> >
>>>
>>>
>>>
>>>
>>>
>>>
>>> [Non-text portions of this message have been removed]
>>>
>>
>>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[David Saff]

Nat,

There's two because we instantiate BlockJUnit4TestRunner
programmatically at one point in the runners (Theories, to be exact).
Your subclass must have the constructor MyRunner(Class<?> testClass),
as indicated in the RunWith javadoc (which you've probably not had
reason to read in years.  :-)

   David Saff

On Thu, Jun 19, 2008 at 11:33 AM, nat_pryce <nat.pryce@...> wrote:

> One other uncertainty I had with the new API.  BlockJUnit4TestRunner
> has two constructors, one which takes a TestClass and one which takes
> a Class delegates to the former.
>
> Why two?
>
> Which should I override for my subclass?  That is, which does the
> framework use to create a test-runner?
>
> --Nat
>
> --- In junit@..., "Kent Beck" <kentb@...> wrote:
>>
>> Nat,
>>
>> I'm glad the new format worked better for you. BlockJUnit4TestRunner
> and its
>> supporting cast are intended to be published in the next release.
> However,
>> they are new enough that we wanted to verify their efficacy and give
>> ourselves a chance to refine them before many people used them.
>>
>> Point well taken on the redundancy of deprecation and moving the
> classes.
>> We'll move them back before releasing. We will compile the final release
>> with Java 5 as well.
>>
>> Thank you very much for the feedback.
>>
>> Regards,
>>
>> Kent Beck
>> Three Rivers Institute
>>
>>   _____
>>
>> From: junit@... [mailto:junit@...] On Behalf Of
>> nat_pryce
>> Sent: Thursday, June 19, 2008 3:16 AM
>> To: junit@...
>> Subject: [junit] Re: 4.5 release candidate
>>
>>
>>
>> I've ported the jMock runner over to the new structure. Here are some
>> comments on the experience.
>>
>> I extended BlockJUnit4ClassRunner and override the invoke(...) method
>> to verify the mock objects after the test has run, but before tear-down.
>>
>> This way reduces the amount of code in the custom runner. I also
>> didn't have to duplicate existing functionality because the invoke
>> method let me hook in at the right point.
>>
>> However, I still had to use classes in the org.junit.internal package,
>> which feels wrong. Have I missed the right way of doing this?
>>
>> Other niggles...
>>
>> - The classes are compiled for Java 6 only, but only seem to need
>> language features from 5 and above. Can the release be compiled for
>> Java 5?
>>
>> - The JUnit 4.4 classes have been deprecated *and* moved to another
>> package, which breaks any code that used them. There's no point in
>> doing both. Either break backward compatability or keep backward
>> compatability and deprecate the classes. I'd prefer the latter, since
>> it will allow me to do a jMock with new features supporting both JUnit
>> 4.4 and 4.5 and then release a version that brings support forward to
>> 4.5 onwards.
>>
>> Cheers,
>> --Nat.
>>
>> --- In junit@yahoogroups. <mailto:junit%40yahoogroups.com> com, "Nat
> Pryce"
>> <nat.pryce@> wrote:
>> >
>> > JUnit 4.5 breaks jMock 2 because the TestMethod class has been moved
>> > to a different package.
>> >
>> > It's our fault for subclassing JUnit4ClassRunner, but it would be nice
>> > if JUnit4ClassRunner did not change at all in this release.
>> >
>> > --Nat
>> >
>> > 2008/6/16 Kent Beck <kentb@>:
>> > > All,
>> > >
>> > > Following our discussions last week, we have incorporated the old
>> > > JUnit4ClassRunner into 4.5. (The new runner is called
>> BlockJUnit4ClassRunner
>> > > because it is organized as a "block" of "statements" instead of
> nested
>> > > procedures). Those of you who have written custom runners, we'd
>> appreciate
>> > > it if you could try out the release candidate to make sure it
>> supports your
>> > > existing runners.
>> > >
>> > > Next up, release notes and then out the door!
>> > >
>> > > Whew!
>> > >
>> > > Kent Beck
>> > > Three Rivers Institute
>> > >
>> > >
>> >
>>
>>
>>
>>
>>
>>
>> [Non-text portions of this message have been removed]
>>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Nat Pryce]

It works fine.  The new JMock test runner now passes all its tests.

Thanks,
    --Nat.

2008/6/24 David Saff <david@...>:

> Nat,
>
> Good suggestion. It's implemented in the new JUnit 4.5 beta 2, now
> available for download. Let me know if it makes things better.
>
> David Saff
>
> On Sat, Jun 21, 2008 at 2:47 PM, Nat Pryce <nat.pryce@...> wrote:
>> I've found a serious limitation with the new API: there's no easy way
>> to insert a statement into the chain of decorators so that it gets
>> access to the test object.
>>
>> I originally inserted jMock's verification step after the test method
>> was invoked, by overriding invoke(...) and wrapping my own Statement