|
»
»
« Return to Thread: First Test - Ignoring addListener()
Re: First Test - Ignoring addListener()
by Nat Pryce
::
Rate this Message:
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
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
> 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
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
« Return to Thread: First Test - Ignoring addListener()
| Free embeddable forum powered by Nabble | Forum Help |
