|
»
»
»
4.5 release candidate
|
View:
New views
13 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
Re: Re: 4.5 release candidate
by Nat Pryce
::
Rate this Message:
It's in the jmock2-junit4.5 branch in the jMock subversion repository.
Branch URL: http://svn.codehaus.org/jmock/branches/jmock2-junit4.5 The test runner itself, in FishEye: http://svn.jmock.codehaus.org/browse/jmock/branches/jmock2-junit4.5/src/org/jmock/integration/junit4/JMock.java --Nat 2008/6/30 David Saff <david@...>: > Nat, > > Would you mind sharing the source? Is it checked in? I'm curious to > see it. Thanks, > > David Saff > > On Wed, Jun 25, 2008 at 8:09 AM, Nat Pryce <nat.pryce@...> wrote: >> 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 >>>> 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 >>>> >>>> >>>> >>>> >>> >> > |
|
|
Re: Re: 4.5 release candidate
by David Saff
::
Rate this Message:
Thanks--it looks about as good as I'd hoped!
David Saff On Mon, Jun 30, 2008 at 10:55 AM, Nat Pryce <nat.pryce@...> wrote: > It's in the jmock2-junit4.5 branch in the jMock subversion repository. > > Branch URL: http://svn.codehaus.org/jmock/branches/jmock2-junit4.5 > > The test runner itself, in FishEye: > http://svn.jmock.codehaus.org/browse/jmock/branches/jmock2-junit4.5/src/org/jmock/integration/junit4/JMock.java > > --Nat > > 2008/6/30 David Saff <david@...>: > >> Nat, >> >> Would you mind sharing the source? Is it checked in? I'm curious to >> see it. Thanks, >> >> David Saff >> >> On Wed, Jun 25, 2008 at 8:09 AM, Nat Pryce <nat.pryce@...> wrote: >>> 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 >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>> >>> >> > |
|
|
Re: Re: 4.5 release candidate
by Steve Freeman-4
::
Rate this Message:
Whiel you're at it, could you check that junit is in sync with
Hamcrest? I believe some of the templating has changed. S Steve Freeman http://www.mockobjects.com Winner of the Agile Alliance Gordon Pask award 2006 |
|
|
Re: Re: 4.5 release candidate
by David Saff
::
Rate this Message:
Johannes,
Did you get a chance to write a test? Any help I can provide? Thanks, David Saff On Thu, Jun 26, 2008 at 1:50 PM, Johannes Link <jl@...> wrote: > I knew I wouldn't be able to trick you into doing my work ;-) > > Thanks for the offer; I'll have a shot at it and get back to you on > Monday. Would that be early enough? > > Johannes > > --- In junit@..., "Kent Beck" <kentb@...> wrote: >> >> Johannes, >> >> I apologize for not getting back to you sooner about this. I'll make > you a >> deal. I'll put the method back in if you supply the unit test for it. (I >> looked at it and couldn't think of how to test it.) >> >> CVS head contains a version that includes the missing Suite > constructor. Let >> me know if it works for you. >> >> Cheers, >> >> Kent Beck >> Three Rivers Institute > > |
|
|
Re: Re: 4.5 release candidate
by Nat Pryce
::
Rate this Message:
Are you planning to leave the block test runner in an internal
package? Or will you move to a public package before release? Or in a future release? If you intend to move it at some time, it would be easiest for me if you move it before the 4.5 release, so I don't have to change jMock to track JUnit releases. --Nat 2008/6/30 David Saff <david@...>: > Thanks--it looks about as good as I'd hoped! > > David Saff > > On Mon, Jun 30, 2008 at 10:55 AM, Nat Pryce <nat.pryce@...> wrote: >> It's in the jmock2-junit4.5 branch in the jMock subversion repository. >> >> Branch URL: http://svn.codehaus.org/jmock/branches/jmock2-junit4.5 >> >> The test runner itself, in FishEye: >> >> http://svn.jmock.codehaus.org/browse/jmock/branches/jmock2-junit4.5/src/org/jmock/integration/junit4/JMock.java >> >> --Nat >> >> 2008/6/30 David Saff <david@...>: >> >>> Nat, >>> >>> Would you mind sharing the source? Is it checked in? I'm curious to >>> see it. Thanks, >>> >>> David Saff >>> >>> On Wed, Jun 25, 2008 at 8:09 AM, Nat Pryce <nat.pryce@...> wrote: >>>> 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 >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > |
|
|
RE: Re: 4.5 release candidate
by kentb
::
Rate this Message:
David,
Johannes sent me a test over the weekend. Perhaps you and I can integrate it today (I'm sending this publicly so everyone here knows Johannes was on the ball and I'm being slow). Cheers, Kent _____ From: junit@... [mailto:junit@...] On Behalf Of David Saff Sent: Tuesday, July 01, 2008 6:42 AM To: junit@... Subject: Re: [junit] Re: 4.5 release candidate Johannes, Did you get a chance to write a test? Any help I can provide? Thanks, David Saff On Thu, Jun 26, 2008 at 1:50 PM, Johannes Link <jl@johanneslink. <mailto:jl%40johanneslink.net> net> wrote: > I knew I wouldn't be able to trick you into doing my work ;-) > > Thanks for the offer; I'll have a shot at it and get back to you on > Monday. Would that be early enough? > > Johannes > > --- In junit@yahoogroups. <mailto:junit%40yahoogroups.com> com, "Kent Beck" <kentb@...> wrote: >> >> Johannes, >> >> I apologize for not getting back to you sooner about this. I'll make > you a >> deal. I'll put the method back in if you supply the unit test for it. (I >> looked at it and couldn't think of how to test it.) >> >> CVS head contains a version that includes the missing Suite > constructor. Let >> me know if it works for you. >> >> Cheers, >> >> Kent Beck >> Three Rivers Institute > > [Non-text portions of this message have been removed] |
|
|
Re: Re: 4.5 release candidate
by David Saff
::
Rate this Message:
Sorry, all. Should know to nudge privately, praise publicly.
David Saff On Tue, Jul 1, 2008 at 10:41 AM, Kent Beck <kentb@...> wrote: > David, > > Johannes sent me a test over the weekend. Perhaps you and I can integrate it > today (I'm sending this publicly so everyone here knows Johannes was on the > ball and I'm being slow). > > Cheers, > > Kent > > _____ > > From: junit@... [mailto:junit@...] On Behalf Of > David Saff > Sent: Tuesday, July 01, 2008 6:42 AM > To: junit@... > Subject: Re: [junit] Re: 4.5 release candidate > > Johannes, > > Did you get a chance to write a test? Any help I can provide? Thanks, > > David Saff > > On Thu, Jun 26, 2008 at 1:50 PM, Johannes Link <jl@johanneslink. > <mailto:jl%40johanneslink.net> net> wrote: >> I knew I wouldn't be able to trick you into doing my work ;-) >> >> Thanks for the offer; I'll have a shot at it and get back to you on >> Monday. Would that be early enough? >> >> Johannes >> >> --- In junit@yahoogroups. <mailto:junit%40yahoogroups.com> com, "Kent > Beck" <kentb@...> wrote: >>> >>> Johannes, >>> >>> I apologize for not getting back to you sooner about this. I'll make >> you a >>> deal. I'll put the method back in if you supply the unit test for it. (I >>> looked at it and couldn't think of how to test it.) >>> >>> CVS head contains a version that includes the missing Suite >> constructor. Let >>> me know if it works for you. >>> >>> Cheers, >>> >>> Kent Beck >>> Three Rivers Institute >> >> > > [Non-text portions of this message have been removed] > > |
|
|
RE: Re: 4.5 release candidate
by kentb
::
Rate this Message:
Nat,
We just moved BlockJUnit4ClassRunner and friends to the published side of the packages. We keep published code API compatible for at least one release, although once it's been deprecated for a release we will likely delete it. Regards, Kent Beck Three Rivers Institute _____ From: junit@... [mailto:junit@...] On Behalf Of Nat Pryce Sent: Tuesday, July 01, 2008 7:01 AM To: junit@... Subject: Re: [junit] Re: 4.5 release candidate Are you planning to leave the block test runner in an internal package? Or will you move to a public package before release? Or in a future release? If you intend to move it at some time, it would be easiest for me if you move it before the 4.5 release, so I don't have to change jMock to track JUnit releases. --Nat 2008/6/30 David Saff <david@... <mailto:david%40saff.net> >: > Thanks--it looks about as good as I'd hoped! > > David Saff > > On Mon, Jun 30, 2008 at 10:55 AM, Nat Pryce <nat.pryce@gmail. <mailto:nat.pryce%40gmail.com> com> wrote: >> It's in the jmock2-junit4.5 branch in the jMock subversion repository. >> >> Branch URL: http://svn.codehaus <http://svn.codehaus.org/jmock/branches/jmock2-junit4.5> .org/jmock/branches/jmock2-junit4.5 >> >> The test runner itself, in FishEye: >> >> http://svn.jmock. <http://svn.jmock.codehaus.org/browse/jmock/branches/jmock2-junit4.5/src/org /jmock/integration/junit4/JMock.java> codehaus.org/browse/jmock/branches/jmock2-junit4.5/src/org/jmock/integration /junit4/JMock.java >> >> --Nat >> >> 2008/6/30 David Saff <david@... <mailto:david%40saff.net> >: >> >>> Nat, >>> >>> Would you mind sharing the source? Is it checked in? I'm curious to >>> see it. Thanks, >>> >>> David Saff >>> >>> On Wed, Jun 25, 2008 at 8:09 AM, Nat Pryce <nat.pryce@gmail. >>>> It works fine. The new JMock test runner now passes all its tests. >>>> >>>> Thanks, >>>> --Nat. >>>> >>>> 2008/6/24 David Saff <david@... <mailto:david%40saff.net> >: >>>> >>>>> 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@gmail. >>>>>> 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@gmail. <mailto:nat.pryce%40gmail.com> >>>>>>> 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@yahoogroups. <mailto:junit%40yahoogroups.com> com, >>>>>>>> >>>>>>>> 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@yahoogroups. <mailto:junit%40yahoogroups.com> com >>>>>>>> Of >>>>>>>> nat_pryce >>>>>>>> Sent: Thursday, June 19, 2008 3:16 AM >>>>>>>> To: junit@yahoogroups. <mailto:junit%40yahoogroups.com> com >>>>>>>> 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, >>>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > [Non-text portions of this message have been removed] |
|
|
Re: Re: 4.5 release candidate
by David Saff
::
Rate this Message:
I've pinged over on that list. If there's a new release version of
hamcrest soon, we'll include it. David Saff On Tue, Jul 1, 2008 at 2:34 AM, Steve Freeman <smgfreeman@...> wrote: > Whiel you're at it, could you check that junit is in sync with > Hamcrest? I believe some of the templating has changed. > > S > > Steve Freeman > http://www.mockobjects.com > > Winner of the Agile Alliance Gordon Pask award 2006 > > |
|
|
Re: Re: 4.5 release candidate
by Nat Pryce
::
Rate this Message:
2008/7/1 Kent Beck <kentb@...>:
> We just moved BlockJUnit4ClassRunner and friends to the published side of > the packages. We keep published code API compatible for at least one > release, although once it's been deprecated for a release we will likely > delete it. That's great. I've just updated from CVS to build a snapshot and noticed that every time I update I get a merge conflict in junit.runner.Version because it has was changed by the Ant build. It would be easier to track JUnit development if the autogenerated code wasn't checked into CVS. --Nat |
|
|
RE: Re: 4.5 release candidate
by Daniel Brolund-2
::
Rate this Message:
Hi Kent,
I got a little annoyed with having to change the JVM in eclipse in order for the ant build to make 1.5 compatibel class files, so I took the liberty of submitting a patch of the build.xml file to make sure that the byte code always will be 1.5, regardless of JVM (1.5+) used. The patch is in the bugs session in SourceForge, together with a more detailed description. I made some other smaller changes to remove duplication and communicate intent better as well. Cheers Daniel On Thu, 2008-06-19 at 08:08 -0700, Kent Beck 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] > > > > > |
|
|
Re: Re: 4.5 release candidate |
