Testing GOF Template Method Pattern

[T P D-2]

I wish to test the following class, which implements the GOF Template
Method Pattern:

public abstract class Foo extends Parent {
  protected void setup() {}
  protected void teardown() {};
  @Override public void overriddenMethod() {
    setup();
    super.overriddenMethod();
    teardown();
  }
}

1. How can I use jMock to test that overriddenMethod() in fact does call
setup() and teardown(), and in the order setup,
(super.)overriddenMethod(), teardown?

(Note that setup and teardown are not abstract, as derived classes may
be fine with their default no-op definitions.)

2. In general, is there a way with jMock to test that a class method
calls super.method?

3. Is this something I should be testing at all? My previous experience
is working in environments that mandate, with few exceptions, 100% code
coverage, where this would be expected to be covered.

Thanks,
Tom

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Stephen Smith-2]

If your overriden method is doing so little, it should be tested implicitly not
tested explicitly.

On Fri 27/03/09 13:07 , T P D lists@... sent:

> I wish to test the following class, which implements the GOF Template
>
> Method Pattern:
>
>
>
> public abstract class Foo extends Parent {
>
> protected void setup() {}
>
> protected void teardown() {};
>
> @Override public void overriddenMethod() {
>
> setup();
>
> super.overriddenMethod();
>
> teardown();
>
> }
>
> }
>
>
>
> 1. How can I use jMock to test that overriddenMethod() in fact does call
>
> setup() and teardown(), and in the order setup,
>
> (super.)overriddenMethod(), teardown?
>
>
>
> (Note that setup and teardown are not abstract, as derived classes may
>
> be fine with their default no-op definitions.)
>
>
>
> 2. In general, is there a way with jMock to test that a class method
>
> calls super.method?
>
>
>
> 3. Is this something I should be testing at all? My previous experience
>
> is working in environments that mandate, with few exceptions, 100% code
>
> coverage, where this would be expected to be covered.
>
>
>
> Thanks,
>
> Tom
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe from this list, please visit:
>
>
>
>
> http://xircles.codehaus.org/manage_email
>
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Steve Freeman-2]

I think you might be asking the wrong question.

First, our instinct would be to replace the templating with  
composition, pass an object into Foo that implements setup and  
teardown (which you can mock) and have Foo call that. Template classes  
often suggest that there are two concepts squashed into one class.

If you can't do that, then you could argue that it's kind of  
meaningless to test the abstract class and that the thing to do is  
write appropriate tests for its subclasses.

If you need to test some corner detail of Foo, then the best thing is  
probably to create one or more test subclasses with assertions in the  
template methods to make the point.

Finally, if you use the ClassImposteriser, you can mock a class and I  
think it will work with abstract classes.

S.

On 27 Mar 2009, at 13:07, T P D wrote:

> I wish to test the following class, which implements the GOF  
> Template Method Pattern:
>
> public abstract class Foo extends Parent {
> protected void setup() {}
> protected void teardown() {};
> @Override public void overriddenMethod() {
>   setup();
>   super.overriddenMethod();
>   teardown();
> }
> }
>
> 1. How can I use jMock to test that overriddenMethod() in fact does  
> call setup() and teardown(), and in the order setup,  
> (super.)overriddenMethod(), teardown?
>
> (Note that setup and teardown are not abstract, as derived classes  
> may be fine with their default no-op definitions.)
>
> 2. In general, is there a way with jMock to test that a class method  
> calls super.method?
>
> 3. Is this something I should be testing at all? My previous  
> experience is working in environments that mandate, with few  
> exceptions, 100% code coverage, where this would be expected to be  
> covered.

Steve Freeman
Winner of the Agile Alliance Gordon Pask award 2006

http://www.m3p.co.uk

M3P Limited.
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 03689627



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email