RE: First Test - Ignoring addListener()

Thanks for your input Nat,
 
However it's not clear to me how Greg can apply your technique to his usecase.
 
Giving it a try, so basically we would call Presenter.addListener() pass to it a mock that has an expectation set similar to:

public class RunAction<T> implements Action {
     private ViewListener<T> listener;
 
     public void succeedGiving(T result) {
          checkCallback();
          listener.run();
     }
 
    ...<snip><snip>
 
   private void checkCallback() {
      if(callback == null) {
         Assert.fail("run action not scheduled");
      }
   }
 
   public Object invoke(Invocation invocation) throws  Throwable {
      listener = (ViewListener<T>)invocation.getParameter(invocation.getParameterCount()-1);
      return null;
   }
}

context.checking(new Expectations() {{
        oneOf(mockView).addListener(with(any(IPresenter.class))); will(callRunMethod);
    }});

The above might work if run() method is exposed through the listener interface. Greg is that possible? Without seeing your code it's hard to work on a solution.
 
Nat, let me know if i'm off the tracks here.


________________________________

From: Nat Pryce [mailto:nat.pryce@...]
Sent: Thu 4/9/2009 2:12 PM
To: user@...
Subject: Re: [jmock-user] First Test - Ignoring addListener()



2009/4/9 Jeudy, Guillaume <gjeudy@...>:
> Hi,
>
> I don't know how you setup your tests but if you have a separate folder containing test classes with exactly the same package structure as your production classes you should be able to make you run() method package-private or protected. That way you don't give on too much encapsulation and you still allow your PresenterTest class to see the Presenter run method.
>

But then the tests aren't exercising the object in the same way as
it's used in the production code, so there's a risk of a defect
slipping in, and of tests diverging from the code when either are
changed.  That's why I prefer to put tests in a different package from
the production code: they are forced to exercise the object through
its API without reaching in through some backdoor.  And, if that's
difficult, it pushes me to sort out the design problems that are
making it difficult.

In this case, I'd implement an Action that held on to the listener and
let you call back to it from the test.  For a simple example, see
http://www.jmock.org/gwt.html.

--Nat

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

    http://xircles.codehaus.org/manage_email







____________________________________________________________________________________________________
This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic email or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply email so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you.


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

    http://xircles.codehaus.org/manage_email