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%40gmail.com">nat.pryce
gmail.com> 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%40saff.net">davidsaff.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%40gmail.com">nat.prycegmail.com> wrote:
>>> It works fine. The new JMock test runner now passes all its tests.
>>>
>>> Thanks,
>>>; --Nat.
>>>
>>> 2008/6/24 David Saff < david%40saff.net">davidsaff.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%40gmail.com">nat.prycegmail.com> 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%40gmail.com">nat.prycegmail.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%40yahoogroups.com">junityahoogroups.com, "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.
