« Return to Thread: First Test - Ignoring addListener()
RE: First Test - Ignoring addListener()
by Guillaume Jeudy
::
Rate this Message:
Maybe the presenter does not add itself to the view after all. I see how the run() method can be called.
Greg probably creates an anonymous listener class inside the Presenter, passes it to View.addListener() and can call private run() inline from the listener code.
I found that in the following example: http://www.atomicobject.com/files/PresenterFirstExample.zip
But your last comment makes alot of sense anyways. Then no need to mess with addListener(), once Presenter and View are wired by a 3rd party class, presenter can then be tested by calling the view event generating method.
________________________________
From: Nat Pryce [mailto:nat.pryce@...]
Sent: Thu 4/9/2009 2:42 PM
To: user@...
Subject: Re: [jmock-user] First Test - Ignoring addListener()
2009/4/9 Nat Pryce <nat.pryce@...>:
> 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.I should have added, the awkward design smell here is that the
presenter adds *itself* as a listener to the view. I would expect
that connection to be established by some third party.
There are three peers: the presenter, the model and the view. But
they are internal components of something else (maybe the application,
or perhaps a subsystem). That thing should be connecting them up: in
this case passing the view's control interface to the presenter's
constructor and registering the presenter to receive notifications
from the view.
Then the whole issue of ignoring the addListener call goes away. The
unit test demonstrates how the presenter behaves if it receives view
notifications, and it's up to the user of the presenter to ensure that
it does receive them.
--Nat
--
http://www.natpryce.com <http://www.natpryce.com/>
---------------------------------------------------------------------
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
Greg probably creates an anonymous listener class inside the Presenter, passes it to View.addListener() and can call private run() inline from the listener code.
I found that in the following example: http://www.atomicobject.com/files/PresenterFirstExample.zip
But your last comment makes alot of sense anyways. Then no need to mess with addListener(), once Presenter and View are wired by a 3rd party class, presenter can then be tested by calling the view event generating method.
________________________________
From: Nat Pryce [mailto:nat.pryce@...]
Sent: Thu 4/9/2009 2:42 PM
To: user@...
Subject: Re: [jmock-user] First Test - Ignoring addListener()
2009/4/9 Nat Pryce <nat.pryce@...>:
> 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.
presenter adds *itself* as a listener to the view. I would expect
that connection to be established by some third party.
There are three peers: the presenter, the model and the view. But
they are internal components of something else (maybe the application,
or perhaps a subsystem). That thing should be connecting them up: in
this case passing the view's control interface to the presenter's
constructor and registering the presenter to receive notifications
from the view.
Then the whole issue of ignoring the addListener call goes away. The
unit test demonstrates how the presenter behaves if it receives view
notifications, and it's up to the user of the presenter to ensure that
it does receive them.
--Nat
--
http://www.natpryce.com <http://www.natpryce.com/>
---------------------------------------------------------------------
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
winmail.dat (8K) « Return to Thread: First Test - Ignoring addListener()
| Free embeddable forum powered by Nabble | Forum Help |
