Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The general idea of unit testing such a class would be, like for any other class :</p> <ul> <li>create Mock version of the dependencies (Display, EventBus, etc...)</li> <li>set expectations on what the depdencies should do when the Presenter works</li> <li>exercice the Presenter and check the expectations</li> </ul> <p>However there are a couple of issues with your version of the Presenter :</p> <ul> <li><p>The loadDbData() method is not showed, but I assumed it means the Presenter also has access to some other component that does the fetching. Can this component be abtracted in a dependency, and mocked liked the rest ? </p></li> <li><p>Then there is the testing of bind(). The only responsibility of your Presenter in this method is to set up callbacks on some buttons provided by the Display. What you want to test is both : </p> <ul> <li>That the callbacks are set</li> <li>That the set callbacks do the expected things </li> </ul></li> </ul> <p>A few ideas to help with the later : </p> <p>You can reduce the coupling between Presenter and Button. If possible, change the Display interface from :</p> <pre><code>Button getAddButton(); </code></pre> <p>to </p> <pre><code>addAddButtonClickedHandler(ClickHandler); </code></pre> <p>This means your Presenter does not have to use a Display object that returns actual BUtton</p> <p>You can reduce the callbacks content to calling a single method, that you can then test in isolation </p> <pre><code>protected void bind() { display.addAddButtonClickHandler(new ClickHandler() { public void onClick(ClickEvent) { fireAdded(); } }); } // The fireAdded function can be tested independenty of the Display, potentially with // a mock EventBus protected void fireAdded() { event.fireEvent(....) } </code></pre> <p>If you really want to check that the callbacks are properly set, than you can use a 'Dummy' implementation of the Display class, that provides you a list of all the callbacks, and let you call them</p> <pre><code>private class DummyDisplay implements Display { private List&lt;ClickHandler&gt; addButtonClickHandlers; public void addAddButtonClickHandler(ClickHandler handler) { addButtonClickHandlers.add(handler); } public void fireAddButtonClick() { for (ClickHandler h in addButtonClickHandlers) { h.onClick(new ClickEvent()); } } // .... } </code></pre> <p>Then your test would : </p> <ul> <li>create a presenter with such a dummy display</li> <li>use bind to set the callbacks</li> <li>use display.fireAddButtonClick() to simulate a user clicking</li> <li>check that has the result of the click, the effects of fireAdded are seen</li> </ul> <p>This type of class (that mostly glue other classes together) can tend to be hard to test ; at some point, it the other classes are thoroughly tested it can become slightly counter productive to concentrate on the gluers, rather than the glued.</p> <p>Hoping this helps. </p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload